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

[Rich Felker <dalias@aerifal.cx>]

On Sun, Aug 12, 2012 at 01:38:02AM -0400, Rich Felker wrote:
> The first main question is what protocol to use. One really simple
> choice would be a plain text protocol where the name/uid of requested
> user is sent over a socket (probably a datagram unix socket) and the
> response comes back in standard colon-delimited passwd format for the
> existing passwd code to parse. This seems very clean, but as far as I
> know it doesn't have any existing implementations.
> 
> Alternatively, we could make musl speak an existing query language
> (e.g. LDAP) directly, such that it could interface with any existing
> server out there that speaks the chosen protocol, or with a proxy that
> translates to other protocols like NIS.

A third approach: using the nscd protocol used by glibc/nss. This
would allow musl-linked binaries running as guests on glibc-based
systems with nscd to perform user lookups through whatever service the
host system was using, without any further configuration. The glibc
nscd daemon would not be useful itself on musl-based systems, since it
depends on glibc/nss, but a drop-in clone for it could easily be
written and later fleshed-out with support for NIS, LDAP, and any
other potentially-interesting user database backends.

If folks think this third option is a good one, we'll need to dig up
(or reverse engineer..?) specs on how the nscd protocol works. It
might be a good idea to do this first before making a decision anyway,
since if the protocol is bad enough (bloat, robustness failures, etc.)
we might need to pick something else even if it does have other good
qualities..

Rich