Date: Tue, 4 Mar 1997 06:57:09 -0800 From: "M.R.Murphy" <mrm@Mole.ORG> To: adam@veda.is, wollman@lcs.mit.edu Cc: current@freebsd.org Subject: Re: cvs commit: src/usr.bin/su su.1 su.c Message-ID: <199703041457.GAA14620@meerkat.mole.org>
next in thread | raw e-mail | index | archive | help
> From owner-freebsd-current@freefall.freebsd.org Tue Feb 25 07:59:43 1997 > Date: Tue, 25 Feb 1997 10:06:47 -0500 > From: Garrett Wollman <wollman@lcs.mit.edu> > To: Adam David <adam@veda.is> > Cc: current@freebsd.org > Subject: Re: cvs commit: src/usr.bin/su su.1 su.c > > <<On Mon, 24 Feb 1997 23:39:55 +0000 (GMT), Adam David <adam@veda.is> said: > > > Please leave it as it is now. If you make root the only member of wheel, > > that gives the behaviour that you seek. This is naturally intuitive. > > > wheel:*:0:root,... #named users can su > > wheel:*:0:root #"only root can su" > > wheel:*:0: #anyone can su > > This is very counterintuitive, actually, since root is a member of > group `wheel' regardless of whether it's listed in /etc/group or not. I'll grant that the overloading of the use of the "wheel" group might have been an injudicious choice. I prefer sudo :-) > > I have long believed that the current implementation of group checking > in the `su' command is a crock. The correct behavior of the command > would be to call getgroups(2) and check the result for a GID of 0. > The current behavior allows the three cases mentioned above: 1) only root can su, 2) named users can su, 3) anyone can su How would the "correct behavior of the command to call getgroups and check the result for a GID of 0" provide for the three cases above without enumerating all users as in 2)? How would a changed behavior be more flexible? How would a changed behavior interact with the limitation on the number of members enumerated in a group? The current behavior will provide for the "check the result for a GID of 0" case with enumeration within the limitation of number of members allowed in a group. The current behavior would seem to be more flexible, and it works as it is. It also seems intuitive to some, perhaps not so to others. In either case, don't fix what ain't broke. -- Mike Murphy mrm@Mole.ORG +1 619 598 5874 Better is the enemy of Good
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703041457.GAA14620>