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

[idunham@lavabit.com]

> Presumably at some point, musl will be used in environments where it's
> not feasible to have the entire user database in a flat password file.
> Despite NIS being hideous, largish institutions use it for this
> reason; presumably LDAP is a much better option, and there may be
> other options still I'm not aware of.

Out of curiosity, is PAM excluded from consideration? Does it require a
dynamically-loaded library?
And will the pam-lite source ever show up somewhere? ;)

> What I'm looking for is a way to allow musl to access user data that's
> not provided with flat files in /etc, but without bloating musl or
> introducing dependencies on abominations like RPC.
>
> The idea I have is to add a single lookup method to musl, whereby it
> can query a local daemon of some sort for user information in a clean,
> simple protocol. Such a daemon can in turn translate to NIS, if
> desired, or to SQL db queries, or to whatever back-end the admin wants
> to use. I'm fairly settled on this general approach, but since I'm not
> at all familiar with the existing approaches, I'd like to seek some
> further input.
>
> The first main question is what protocol to use. One really simple
> choice would be a plain text protocol where the name/uid of requested
> user is sent over a socket (probably a datagram unix socket) and the
> response comes back in standard colon-delimited passwd format for the
> existing passwd code to parse. This seems very clean, but as far as I
> know it doesn't have any existing implementations.

I presume, for security reasons, that this would be the contents of
/etc/passwd as found on shadow-enabled systems...but how does the password
get authenticated?
Or are unix sockets immune to sniffing?

> Alternatively, we could make musl speak an existing query language
> (e.g. LDAP) directly, such that it could interface with any existing
> server out there that speaks the chosen protocol, or with a proxy that
> translates to other protocols like NIS.

If you do any sort of communication over sockets/networks/... with a
daemon, I'd suggest having musl communicate with a PAM-capable daemon.
PAM is meant for scenarios like this.

Isaac Dunham