[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <10bce7f58679d9e976e3ddf95d11d995@exys.org>
Date: Mon, 13 Aug 2012 22:14:00 +0200
From: "Arvid E. Picciani" <aep@...s.org>
To: <musl@...ts.openwall.com>
Subject: Re: Design for extensible passwd[/shadow?] db support
On Mon, 13 Aug 2012 15:50:32 -0400, Rich Felker wrote:
> [..] parse the entire /etc/passwd file every time it's called
hm yeah. This stuff is all fairly ugly, which is why i hoped to get it
out
of libc into a high level construct that can be replaced with system
specific parts.
> glibc has a solution for this problem in the form of nscd
The libc daemon from hell :/
A proxy daemon requires much more care and policy.
What happens when it times out, or responses are invalid, how do i
do balancing, ... "Falling back on local database" isn't graceful
degradation. It requires that you anticipate the situation and
make sure there is a fallback user in the passwd for maintenance.
Then security is a whole new topic. Who can access the daemon, what is
the retry policy, how do i handle linux namespaces, and containers...
So many things to deal with...
> 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...
Yes. They're incompatible. I don't see why this is a problem,
but then again i don't work on desktop systems at all.
They're not interesting systems, because resources are so inexpensive.
> I don't think removing ~50 lines of passwd entry lookup code would be
> of much benefit for cutting down size,
no, not at all. But being able to ignore ancient posix and go for
something that gets us to the product faster is something pretty
valuable
for me. Let's take the fairly visible example of musl-android:
it doesn't have /etc/passwd, so i already have to downstream patch
musl.
A proxy does not help me, because the fallback is still on /etc/passwd.
Again, i can only emphasize that these things are so fundamentally
setup
dependent, that i think putting this in libc was a bad choice back
then.
--
Arvid E. Picciani
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.
