>Number:         792
>Category:       bin
>Synopsis:       su(1) ignores primary group, it and id(1) disagree with kernel on group membership
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Feb 10 16:05:05 1995
>Originator:     Daniel Carosone
>Organization:
"bozo softwar confoundation"
>Release:        today
>Environment:
	
System: NetBSD anarres 1.0A NetBSD 1.0A (_anarres_) #10: Thu Jan 26 09:07:33 EST 1995 dan@anarres:/amd/oi/fs/f/l/NetBSD/src/sys/arch/i386/compile/_anarres_ i386


>Description:

I created a temporary account on a new machine while I was setting it
up, with a primary gid of 0. The idea was to let me su and save an
edit of /etc/group.

I discovered that, while id(1) told me I was in group 0, su(1) told me
I was not in the correct group to su.

The su(1) program uses the getgrgid() function, which reads the
/etc/group file for secondary groups. It does not look at the primary
group. id and su should agree, this is clearly a bug, and a simple one
to fix.

I was also unsatified with the fact that it reads the group file to
find out secondary group membership, as this is clearly at odds with
the kernel's permissions checking on filesystem access, and with the
general way that I am accustomed to unix working. To me, the group
membership gets set on login, and is pretty much left alone from
there. Changes to passwd/group files don't become relevant until the
next login for permissions-checking at least.

I went to the source of id(1) to see how it extracted the secondary
group membership from the kernel, so as to use the same mechanism in
su(1).  I discovered that id also uses a variant of the /etc/group
database file access routines, and so there is the possibility for
disagreement between id(1) and the kernel.

I find it very confusing when id tells me I am in the right group to
su, and I can't, or when it tells me I am in the right group to access
a file, and I can't.

>How-To-Repeat:

see above

>Fix:

I was going to send a simple fix for su to check the primary group
also, but I think the problem is larger.  I don't know how to extract
the secondary group membership list from the kernel without frobbing
kmem or requiring /proc to be mounted -- and I suspect that it may be
`hard' and that's why these programs were (re-)written this way.

If anyone has suggestions to make as to how to accomplish this, let me
know and I'll make the changes. I am tempted to use /proc if it's
there, and if not fall back to the current mechanism while printing a
warning that the output may not reflect the kernel's idea of
reality. su is already an suid-0 program, it could frob kmem. I'd rather
not need id to be. I hope there's a better way.

--
Dan.

>Audit-Trail:
>Unformatted: