[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Aug 2012 15:50:32 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Design for extensible passwd[/shadow?] db support
On Mon, Aug 13, 2012 at 09:38:57PM +0200, Arvid E. Picciani wrote:
> On Mon, 13 Aug 2012 15:28:33 -0400, Rich Felker wrote:
>
> >It reads it because ls -l prints the owners of files, and seeing a
> >username rather than a number is a lot more informative.
>
> Oh yeah. Now it would be really horrible to have it build up an ldap
> connection each time you do "ls". People do that in tight loops in
> scripts
> and expect it to have semi-guaranteed runtime properties.
It only does the lookup with -l, and good implementations of ls will
cache the last user lookup (or maybe the last N for some large value
of N) to avoid being slow. Keep in mind, even without any remote
query, getpwuid_r has to parse the entire /etc/passwd file every time
it's called, which is not fast, so apps have a good reason to be doing
caching already.
glibc has a solution for this problem in the form of nscd, one of the
other solutions I proposed. It's a daemon whose purpose was just to
cache lookup results, but since the lookups are performed in the
daemon rather than the client, it could also be used as a translating
proxy to add support for arbitrary backends/protocols.
I have no idea how ugly the nscd protocol is, but if it's clean, I
think we could simply adopt it. musl-native systems would of course
need a new nscd (since the original one is part of glibc and depends
on the libnss mess) but musl binaries running on glibc systems could
even use the existing host nscd. Anyway, to determine if this solution
makes sense, somebody needs to do a bit of research into the nscd
protocol and how bad it is...
> Can we at least have compile-time modules for this, so a
> system-designer
> can choose between different implementations? Maybe then having ldab
> in there
> directly isn't so bad at all. Hidding away the ldap problems in another
> daemon sounds like an attempt to make a one-size-fits-all.
The problem with this is when you copy or static-linked busybox onto a
system that needs non-flat-file user lookups, and it fails to work
right...
I'm actually interesting in making _some_ features in musl
compile-time switchable, but only when they have a large size impact
that would affect really tiny embedded usage. The only examples that
come to mind so far are iconv charsets and crypt hashes. And in this
case, the option would not be to remove the interfaces entirely, only
to remove support for unneeded charsets (in the case of iconv) or
unneeded hashes (in the case of crypt).
I don't think removing ~50 lines of passwd entry lookup code would be
of much benefit for cutting down size, whereas every switch is an
addtional complexity cost (e.g. for cases that must be tested).
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.
