>> 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 concur with some of the others who've commented on this and said that
>it's right the way it is....
>
>I.e. the current method of requiring membership in "wheel" as listed in
>/etc/group is correct.  This is an access control mechanism unique to
>su(1) and it should not be consistent with other uses of gid 0.
>
>In fact there should be no requirement for "wheel" to be gid 0 -- it
>should be possible to make it any old UID.

Thought I can be persuaded that arguments for the later position may be
correct I do not think that any valid argument can be made that a person
listed in the /etc/passwd field as having a primary group with the same ID
number as what ever group su allows should be denied simply because they
are not listed in /etc/groups.  My pervious comment notwithstanding, I
would not mind if I were denied su access because I don't appear in
/etc/group even though my /etc/passwd group is right *if and only if* su
were to print an error to the effect that it was disallowing because of
/etc/group and /etc/passwd mismatch.

---------
Christopher R. Bowman
crb@eng.umd.edu
My home page