Date: Sun, 12 Aug 2012 16:56:43 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Design for extensible passwd[/shadow?] db support On Sun, Aug 12, 2012 at 09:10:16PM +0200, Arvid E. Picciani wrote: > On Sun, 12 Aug 2012 01:38:02 -0400, Rich Felker wrote: > > >What I'm looking for is a way to allow musl to access user data > >that's > >not provided with flat files in /etc, > > I'm not sure why user auth is in libc in the first place. This is not auth, it's just lookups. Translating uids to usernames and back. > >[..] can query a local daemon [..] > > >The first main question is what protocol to use. > > well, so use the existing rpc. it fullfills the given requirements, > and is compatible with the stuff out there. Not an option. It's massively bloated and full of security issues. There is a legitimate need for what NIS provides, but doing it with NIS and the RPC system is backwards and stupid. Putting this backwardsness in libc just creates more cost for people who want to do it right. > >Alternatively, we could make musl speak an existing query language > >(e.g. LDAP) directly > > And pull even more policy into libc? I'm not sure how this is adding policy. I consider the other solution glibc chose, nss, to be policy. It forces your apps to have dynamic loader support in them, forces you to have config files in place and shared libraries present in hard-coded paths, etc. My intent is to minimize any such requirements, and leave them at absolute zero except for people who need giant specially-backed user databases. > Then everyone has to patch > libc to adapt to the local ldap layout? or another config? It's the intent that nobody should ever have to patch libc for the sake of accessing their user database. That's what this thread is about. I'm not familar with how LDAP is used in the wild for this purpose, or if it even is, so I don't know how easy it would be to directly interface with diverse existing LDAP servers, but it seems like it would be a reasonable, simple proxy language for lookups, whereby any customization could go in the proxy. See my later post about nscd; it might be a better choice. > There is a need for the things you want to do here, but i think > this is the line where it's time to go into higher layers. I don't follow. What alternative are your proposing? 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.