getgrnam(3) bug

[Jeff Forys]

In article <762 at yabbie.rmit.oz> rcodi at yabbie.rmit.oz (Ian Donaldson) writes:
> Description:
>	getgrnam(3) fails to read 2nd and subsequent lines of a
>	multi-line group specification.

That isnt the way getgrnam(3) is defined to work in either SVID or
BSD UNIX.  "Getgrnam searches from the beginning of the file until
a group name matching `name' is found and returns a pointer to the
particular structure in which it was found."  Each group is separated
from the next by a newline.  I assume POSIX defines getgrnam(3)
similarly (I dont have a draft handy, so correct me if I'm wrong).

>	...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.

Ah, then BSD groups(1) and initgroups(3) are broken, or at least, more
liberal than they should be.  They are using getgrent() to process thru
the entire file searching for a specific username; it was `easier' to
not remember duplicate group entries and invalidate them.

>	if you have as many people in a group that your favourite editor
>	won't let fit onto a single line;

Use another editor.

>	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)

Awful static limitations which you arent addressing here.  The BUFSIZ
limitation can be resolved by doing block fread()'s and parsing thru
end-of-line.  The MAXGRP define can be raised if necessary, but if your
group is that big, consider using the gid field in "/etc/passwd".  You
need not match the gid field in "/etc/passwd" with a per user entry in
"/etc/group" for it to be effective.
---
Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991)
forys at boulder.Colorado.EDU  -or-  ..!{ncar|nbires}!boulder!forys