getgrnam(3) bug

[Jeff Forys]

In article <769 at yabbie.rmit.oz> rcodi at yabbie.rmit.oz (Ian Donaldson) writes:
>> [If your editor cant handle long lines] Use another editor.
>
> Get serious!

Oh... all right.  You can write a script, or program, to make up
for your particular editors' limitations.  In the case of vi(1),
it would take a long line and make lotsa little short lines out
of it.

> The groups file is meant to be a text file.  It should
> be editable by a text editor.  Any text editor!

Is that so?  Consider an editor that limits the length of a line
to 512 characters.  Does it still qualify it as a "text editor"?
I hope so, since ed(1) -- the "standard text editor" -- has just
such a restriction.  Or, does your definition of a "text" file
change to meet an editors' restrictions?  In that case, what do
you call a binary file in the presence of emacs?  Oh oh...

I'd expect a text file to contain data in "human-readable" form.

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

All true, but irrelevant.  Try adding two entries in your password
file with the same user name, but different user-id's.  What happens
when you log in as that user -- do you have access to files owned
by both user-id's?  Nopers...

> For goodness sakes, fixing getgrnam(3) to scan for all possible group
> entries is hardly going to break any software is it?

Dunno -- I'd have to see all the software.  I can imagine a program
using getgrent() to create a database keyed on group names, or worse,
some home-grown software that automatically manipulates /etc/group...
---
Jeff Forys @ UC/Boulder Engineering Research Comp Cntr (303-492-4991)
forys at boulder.Colorado.EDU  -or-  ..!{ncar|nbires}!boulder!forys