[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150223070443.GC23507@brightrain.aerifal.cx>
Date: Mon, 23 Feb 2015 02:04:43 -0500
From: Rich Felker <dalias@...c.org>
To: Solar Designer <solar@...nwall.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] support alternate backends for the passwd and
group dbs
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
