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.