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

[Rich Felker <dalias@aerifal.cx>]

On Mon, Aug 13, 2012 at 10:14:00PM +0200, Arvid E. Picciani wrote:
> >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.

A proxy daemon factors policy out of libc (where it doesn't belong) to
an isolated component that can be replaced or reconfigured without
breaking any apps (whether they're static or dynamic linked).

> What happens when it times out, or responses are invalid, how do i
> do balancing, ... "Falling back on local database" isn't graceful
> degradation.

These are all issues for implementing the proxy daemon, not for libc
to care about. Since it's a local daemon we're talking about, invalid
responses indicate you've been rooted and timing out indicates your
system has major problems (probably DoS).

> It requires that you anticipate the situation and
> make sure there is a fallback user in the passwd for maintenance.

Normally root is in the local passwd database anyway; it's the actual
_users_ whose identities are shared across networks.

> Then security is a whole new topic. Who can access the daemon, what is
> the retry policy,

All of that is at the daemon level; it's not relevant to libc.

> how do i handle linux namespaces, and containers...
> So many things to deal with...

That's a matter for people setting up these things to deal with.

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

Why does it hurt to attempt reading /etc/passwd if the file doesn't
exist and isn't used?

Rich