Subject: Re: getpw*_r standards
To: Luke Mewburn <lukem@NetBSD.org>
From: Greywolf <firstname.lastname@example.org>
Date: 04/11/2005 19:14:41
[Thus spake Luke Mewburn ("LM: ") Tomorrow...]
LM: I've been considering solutions to this, especially (a):
LM: (1) Deprecate passwd compat. It's kinda handy, but it adds
LM: complexity to the implementation of getpw*() as described above.
Hi, please don't do this one. The granularity offered by +/- entries
in compat mode are just not matched by any other facility we have. It's
nice to be able to arbitrarily allow individuals without having to maintain
separate password files on each machine or throwing the doors wide open
and letting everyone on to a box.
LM: (2) Implement a new netgroup API that provides a "cursor cookie"
LM: (a la FILE * for stdio) to callers of
LM: loop calling getnetgrent
LM: so that internal libc functions such as getpw*(3) can do
LM: netgroup lookups without affecting end user applications
LM: use of netgroup lookups.
Isn't this kind of working around end-programmer folly? If they're doing
anything with netgrents, they should be allocating their own static storage
and doing things in a logical order, no? [I remember having to do this
for password entries once upon a time...]
Does Solaris exhibit this behaviour?
Question: Would it make sense at all to have the get*() as wrappers
around get*_r(), or are get*() sufficiently set in stone that there
would be no gain by doing so? (Probably the latter; I was just thinking
along the lines of any new development, though I suspect that new stuff
would be made reentrant by default...)