Re: [PATCH] support alternate backends for the passwd and group dbs

[Rich Felker <dalias@libc.org>]

On Mon, Feb 23, 2015 at 09:18:43AM +0300, Solar Designer wrote:
> On Mon, Feb 23, 2015 at 01:08:40AM -0500, Rich Felker wrote:
> > On Sun, Feb 22, 2015 at 08:58:10PM -0600, Josiah Worcester wrote:
> > > when we fail to find the entry in the commonly accepted files,  we
> > > query a server over a Unix domain socket on /var/run/nscd/socket.
> > > the protocol used here is compatible with glibc's nscd protocol on
> > > most systems (all that use 32-bit numbers for all the protocol fields,
> > > which appears to be everything but Alpha).
> > 
> > I'm committing with the attached additional changes [...]
> 
> Hmm.  I guess this was discussed before, but I am surprised.  Wasn't
> nscd intended for caching rather than to provide a fallback?  If so,
> does musl intentionally re-purpose it?

There were multiple discussions of how to support alternate backends
in the past, and the main two candidates were a new text-based
protocol over a unix socket that returns the result in passwd/group
file form, and repurposing nscd protocol. While I originally preferred
the former, using nscd has the advantage that, on existing glibc
systems with non-default (possibly even custom nss modules) backends,
everything works out of the box. Using a new protocol/new daemon would
require installing that daemon before any musl-linked binaries could
lookup users/groups, and would require significant custom glue to
integrate with custom site-local backends.

The intended usage for musl binaries running on glibc systems is to
use whatever nscd is already running. Systems with a network-based
user/group db backend should already be running nscd; if not it's easy
to add. Systems just using passwd/group files don't need it anyway.

For musl-native systems, the user is intended to have some choice. The
options should eventually include at least:

1. A featureful generic nscd implementation that uses one or more nss
   modules (optionally static linked into the daemon or dynamically
   loaded) as its backend(s).

2. A simple nscd implementation that just does NIS and LDAP.

At this time neither exists, but it's possible to use glibc nscd if
really needed.

Rich