[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cbc7bedb99ccc4d905e49012d7054aa2@exys.org>
Date: Mon, 13 Aug 2012 11:41:47 +0200
From: "Arvid E. Picciani" <aep@...s.org>
To: <musl@...ts.openwall.com>
Subject: Re: Design for extensible passwd[/shadow?] db support
On Sun, 12 Aug 2012 16:56:43 -0400, Rich Felker wrote:
> I don't follow. What alternative are your proposing?
push user lookup up the stack and force ancient code to link in the
high level lib.
imo, getpwent and the link don't belong into libc. They're only there
because ancient unix
systems had a lot of tools that shared that functionality and an extra
lib would seem
bloat for the little functionality they offered (basicly, it's a shared
/etc/passwd parser,
not a user lookup per se). Then glibc wanted more then that, out of a
real need, and crammed
it into libc as well, because of the inability to break compatibility.
Now, musl _can_ break compatibility with GNU/Linux. Especially if it's
just "link against another lib".
Then you can go to full lengths and rebuild the whole idea of user
lookup, auth, etc.
Another grief i have with PAM is that it is orthogonal to libc.
For a dynamic loaded system, if you design the interface carefully,
this means you can exchange
the auth/user/whatever lib with something else at the packaging level.
For a static linked system, it makes no difference at all.
--
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.
