bin@rhesus.primate.wisc.edu (Brain in Neutral) (07/12/88)
Why does setgid screw up the list of groups that getgroups returns? E.g., in a setuid root program: ngroups = getgroups (NGROUPS, grparry) print groups here... setgid (somegid); ngroups = getgroups (NGROUPS, grparry) print groups here... The group lists printed before and after the setgid are different, at least under Ultrix 1.2 and 2.2. (Typically a group is missing after the setgid). Doing an initgroups after the setgid fixes things (I think). I notice that BSD 4.3 login.c does this. Why is it necessary?
chris@mimsy.UUCP (Chris Torek) (07/24/88)
In article <339@rhesus.primate.wisc.edu> bin@rhesus.primate.wisc.edu (Brain in Neutral) writes: >Why does setgid screw up the list of groups that getgroups returns? Whether it does depends on your definition of `screw up'. setgid(gid) is equivalent to setregid(gid, gid). Among other things, this has to take you out of any group you were in from a previous setregid(). Hence the algorithm is: leavegroup(old_real_gid); leavegroup(old_effective_gid); entergroup(new_real_gid); entergroup(new_effective_gid); If you setgid() to a group you are already in, the two leave and enter calls effectively do nothing; if, however, you setgid to a group you are not now in, you lose the old group. (Solution: use `setregid' to set only the effective or only the real gid.) This behaviour is somewhat bogus, but as long as setregid() is used only to exchange real and effective gid, or to set gid's from a setuid- root program (login) and followed by an initgroups(), everything works. Since setgid() is supposed to be mostly irrelevant given the multiple- group scheme, I guess this has not been considered a serious problem. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris