Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 23 Feb 2015 13:15:14 -0500
From: Rich Felker <>
To: M Farkas-Dyck <>
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 <> 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.


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.