Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 Aug 2012 11:41:47 +0200
From: "Arvid E. Picciani" <>
To: <>
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.