Re: Design for extensible passwd[/shadow?] db support

[Rich Felker <dalias@aerifal.cx>]

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