From: alfie@dcs.warwick.ac.uk (Nick Holloway) Subject: Re: [HELP]: Groups too big in /etc/group Date: Wed, 30 Jun 1993 08:54:56 GMT
In <1993Jun29.031034.817@datasoft.north.net> mark@datasoft.north.net (Mark Buckaway) writes:
> Basically, there is a problem within the /etc/group file that is not
> permitting the system to read the group name. To illustrate what I
> mean here is a ls from an effected directory:
> [...]
>
> In tracking down the problem, I found that truncating this group made
> it work (ie. ls reported bbs and not 100). IMO, there should be no
> restriction on the length on any one group. I might say this is a
> kernel bug, however, I have not seen it mentioned in this group nor
> does booting an older kernel correct this problem.
This is not a kernel bug -- the kernel only deals with the numeric values
for the various uid and gid's.
The problem is the C library. Having a quick browse at the source,
there is a read into a fixed size buffer. The size is 256. The length
of your line is 261 :-(.
What is strange is that the code is in an "#ifdef linux". The alternative
is a call to "getline()". I assume that this routine would do the task
of reading a line from the input stream, extending the buffer as needed.
However, "readline()" doesn't exist in the library. It would also
be used by the password routines. Perhaps H.J. Lu can explain why it
doesn't exist? Perhaps it needs writing?
The code appears to allow dynamic resizing for the number of members
in a group, so given that "readline()" were added, there should be no
limit on the number of members of a group.