Path: utzoo!attcan!uunet!munnari!moncskermit!goanna!yabbie!rcodi
From: rcodi@yabbie.rmit.oz (Ian Donaldson)
Newsgroups: comp.bugs.4bsd
Subject: Re: getgrnam(3) bug
Message-ID: <769@yabbie.rmit.oz>
Date: 17 May 88 00:51:56 GMT
References: <6076@sigi.Colorado.EDU>
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 50

From article <6076@sigi.Colorado.EDU>, by forys@sigi.Colorado.EDU (Jeff Forys):
> In article <762@yabbie.rmit.oz> rcodi@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).

If this is the case, then the definition of the group file is severely
broken, and should be revised.  Having just 1 line per group is a bit
silly in a large user base environment.

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

Get serious!  The groups file is meant to be a text file.  It should
be editable by a text editor.  Any text editor!  If it can't be edited
by any text editor then it is seriously in doubt of being a text file.
 
>>	or if the line exceeds BUFSIZ (1024) characters,

not a problem if the file is a text file

>>	or if the number of members of a group on a single line
>>	exceeds 200 (see getgrent.c)

not a problem if the file is a text file

>  group is that big, consider using the gid field in "/etc/passwd". 

It may be possible in some cases to do this, but in lots this would
not be a solution.

For goodness sakes, fixing getgrnam(3) to scan for all possible group
entries is hardly going to break any software is it?  All software
reading the groups file is supposed to use the getgr*(3) routines anyway.

getpwuid(3) and getpwnam(3) already don't do sequential searches of 
/etc/passwd in 4.3bsd, with the advent of the parallel random passwd database.
The only reason that /etc/group hasn't followed suit is probably because
it never gets big enough to warrant the overheads of database lookup.

Ian D