Date: Mon, 13 Aug 2012 09:50:48 -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 11:41:47AM +0200, Arvid E. Picciani wrote: > 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. "Intentionally break or omit a required standard interface in POSIX and require every application needing the functionality to pull in some third-party library" is not a plan that sounds appealing to me. > imo, getpwent and the link don't belong into libc. They're only Well that's up to the Austin Group, not you. We implement POSIX. Unlike glibc, which (used to) implement Drepper's idea of what POSIX should be changed to. Thankfully now that's changing. > 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. Making /bin/ls depend on dynamic loading modules is a bit disgusting... 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.