getgrnam(3) bug

[per at erix.UUCP]

In article <777 at yabbie.rmit.oz> rcodi at yabbie.rmit.oz (Ian Donaldson) writes:
>From article <123000002 at ishmael>, by cball at ishmael:
>> 		testgroup:*:1234:somebody,somebodyelse,\
>> 		myself,yourself

>Whilst this sounds a good idea initially, I suspect it would break more
>code than its worth.
>How many of you use "cut -d: -f1 /etc/group | something" ...

(I don't...)

>I suspect a lot of maintenance scripts out there would break instantly.

In article <769 at yabbie.rmit.oz> rcodi at yabbie.rmit.oz (Ian Donaldson) writes:
>  All software
>reading the groups file is supposed to use the getgr*(3) routines anyway.

Ahem... Well, maybe maintenance scripts don't qualify as "software"...:-)
More seriously, I suppose "something" would have to be modified to handle
multiple entries for the same group too, if that solution were to be adopted.

I fully agree that the "correct" solution is to define a continuation line
format for the group file, whether it be the one suggested above or something
else. This preserves the current semantics, is consistant with getpwnam(3),
and avoids the ambiguites that may arise due to different passwords/gids
if the "multiple entry" solution is used. Precedence can be found in the
aliases file (and other, I'm sure).

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

I can't see why this is relevant, at least as an argument *for* the multiple
entry solution? Mkpasswd(8) currently silently ignores all occurences after the
first (in the sequential file) of a given name or userid!

--Per Hedeland