getgrnam(3) bug
Ian Donaldson
rcodi at yabbie.rmit.oz
Wed May 11 19:32:56 AEST 1988
Index: /usr/src/lib/libc/gen/getgrnam.c 4.3BSD
Description:
getgrnam(3) fails to read 2nd and subsequent lines of a
multi-line group specification.
Repeat-By:
Add 2 lines to /etc/group like this:
testgroup:*:1234:somebodyelse
testgroup:*:1234:myself
then re-login as "myself" and then try to:
chgrp testgroup anything
where "anything" is any file or directory that you own.
You will be greeted by something like this:
chgrp: You are not a member of the "testgroup" group.
...but upon doing a groups(1) command it is evident that you are
in fact a member of the group.
ie: initgroups(3) used by /bin/login reads the entire group file
and looks for all entries, but getgrnam(3) only looks for
the first line.
Fix:
Pretty obvious. Fix getgrnam(3) to scan the entire group file,
and include all groups in the list.
As for chgrp(1) however, the code that calls getgrnam(3) should
probably be deleted entirely, since this is primarily an
artifact of the days when chgrp(1) was a setuid root program,
and needed to check that you were in a group before actually
using chown(2) to change the file. The kernel chown(2) function
will do the checking for non-root callers in 4.3bsd. Having
this extra call to getgrnam(3) serves nothing but to provide
a more explicit reason for failure than errno can give.
Workaround:
none, if you have as many people in a group that your favourite editor
won't let fit onto a single line; or if the line exceeds BUFSIZ (1024)
characters, or if the number of members of a group on a single
line exceeds 200 (see getgrent.c)
Maybe some use of malloc(3) and realloc(3) within getgrent(3) is needed
here...
Also-present-on:
SunOS 3.3 (4.2bsd-ish)
Vax 4.3bsd
Ian D
More information about the Comp.bugs.4bsd.ucb-fixes
mailing list