Re: Design for extensible passwd[/shadow?] db support

["Arvid E. Picciani" <aep@exys.org>]

On Mon, 13 Aug 2012 15:50:32 -0400, Rich Felker wrote:

> [..] parse the entire /etc/passwd file every time it's called

hm yeah. This stuff is all fairly ugly, which is why i hoped to get it 
out
of libc into a high level construct that can be replaced with system
specific parts.


> glibc has a solution for this problem in the form of nscd

The libc daemon from hell :/
A proxy daemon requires much more care and policy.
What happens when it times out, or responses are invalid, how do i
do balancing, ... "Falling back on local database" isn't graceful
degradation. It requires that you anticipate the situation and
make sure there is a fallback user in the passwd for maintenance.
Then security is a whole new topic. Who can access the daemon, what is
the retry policy, how do i handle linux namespaces, and containers...
So many things to deal with...


> The problem with this is when you copy or static-linked busybox onto 
> a
> system that needs non-flat-file user lookups, and it fails to work
> right...

Yes. They're incompatible. I don't see why this is a problem,
but then again i don't work on desktop systems at all.
They're not interesting systems, because resources are so inexpensive.


> I don't think removing ~50 lines of passwd entry lookup code would be
> of much benefit for cutting down size,

no, not at all. But being able to ignore ancient posix and go for
something that gets us to the product faster is something pretty 
valuable
for me. Let's take the fairly visible example of musl-android:
it doesn't have /etc/passwd, so i already have to downstream patch 
musl.
A proxy does not help me, because the fallback is still on /etc/passwd.

Again, i can only emphasize that these things are so fundamentally 
setup
dependent, that i think putting this in libc was a bad choice back 
then.



-- 
Arvid E. Picciani