[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sun, 12 Aug 2012 20:26:24 -0400 (EDT)
From: idunham@...abit.com
To: musl@...ts.openwall.com
Subject: Re: Design for extensible passwd[/shadow?] db support
> 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
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.
