[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150223181514.GF23507@brightrain.aerifal.cx>
Date: Mon, 23 Feb 2015 13:15:14 -0500
From: Rich Felker <dalias@...c.org>
To: M Farkas-Dyck <strake888@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] support alternate backends for the passwd and
group dbs
On Mon, Feb 23, 2015 at 11:01:11AM -0500, M Farkas-Dyck wrote:
> On 23/02/2015, Rich Felker <dalias@...c.org> wrote:
> > 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.
>
> For nonstatic non-nsc backends, one could alternately have files in
> question on synthetic filesystem, e.g. 9p, so backend program would
> simply be synthetic filesystem server and musl wouldn't need to care.
Generally the only time you use non-static backends is when your user
database is so huge that parsing /etc/passwd over and over would be
prohibitively slow. Think of university or corporate user database
with tens or hundreds of thousands of users. A synthetic filesystem
does not help with this any more than a generated passwd file in /etc
would help; the goal is to get rid of the linear-search-on-each-lookup
performance problem.
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.
