[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120812053802.GA10971@brightrain.aerifal.cx>
Date: Sun, 12 Aug 2012 01:38:02 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: 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.
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.
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.
Any thought on the pros and cons of these or other appraches?
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.
