> > 2. su(1) uses /etc/group instead of current grouplist
> > -----------------------------------------------------
> > 
> > PRs 792 and 2466 both mention that su(1) parses /etc/group for the
> > contents of gid 0 to determine if access is permitted to root.
> > If a user's primary group is 0, but they're not in /etc/groups, things
> > fail.
> > 
> > The suggested solution is to check the users' *current* group list
> > using getgroups() (both primary & supplimentary groups) for
> > existance of gid 0, instead of getpwent(getuid()) and getgrgid(0).
> > This is consistant with other access checks on the system...
> 
> I consider /etc/group & wheel to be an "access control" mechanism for
> su'ing to root (as opposed to being gid 0).  In many modern unixes,
> gid "0" means nothing special (except that it is wheel/root and used
> by su when consulting /etc/group).  Gid 0 set in /etc/passwd should not
> render /etc/group obselete.

We use "sugroup" here.  If "sugroup" is in the group file (well,
getgrent()...) then the user must be a member of the group, otherwise
(if no "sugroup") let anyone try to su.  That way, no "standard" group
is overloaded for this purpose.

Simon.
--
Simon Burge						simonb@telstra.com.au
UNIX Support, CPR Project, Telstra Corp.		+61 3 9634 3974 (Phone)
23/300 LaTrobe St, Melbourne 3000, Australia.		+61 3 9670 1189 (Fax)