From owner-freebsd-current  Tue Mar  4 06:57:54 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id GAA25133
          for current-outgoing; Tue, 4 Mar 1997 06:57:54 -0800 (PST)
Received: from mole.mole.org (marmot.mole.org [204.216.57.191])
          by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id GAA25128
          for <current@freebsd.org>; Tue, 4 Mar 1997 06:57:50 -0800 (PST)
Received: (from mail@localhost) by mole.mole.org (8.6.12/8.6.12) id OAA28327; Tue, 4 Mar 1997 14:58:50 GMT
Received: from meerkat.mole.org(206.197.192.110) by mole.mole.org via smap (V1.3)
	id sma028324; Tue Mar  4 14:58:39 1997
Received: (from mrm@localhost) by meerkat.mole.org (8.6.11/8.6.9) id GAA14620; Tue, 4 Mar 1997 06:57:09 -0800
Date: Tue, 4 Mar 1997 06:57:09 -0800
From: "M.R.Murphy" <mrm@Mole.ORG>
Message-Id: <199703041457.GAA14620@meerkat.mole.org>
To: adam@veda.is, wollman@lcs.mit.edu
Subject: Re: cvs commit:  src/usr.bin/su su.1 su.c
Cc: current@freebsd.org
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> 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