From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1547 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Design for extensible passwd[/shadow?] db support Date: Sun, 12 Aug 2012 13:34:17 -0400 Message-ID: <20120812173417.GS27715@brightrain.aerifal.cx> References: <20120812053802.GA10971@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1344792811 16952 80.91.229.3 (12 Aug 2012 17:33:31 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 12 Aug 2012 17:33:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1548-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 12 19:33:30 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1T0c2X-0001qu-Pl for gllmg-musl@plane.gmane.org; Sun, 12 Aug 2012 19:33:25 +0200 Original-Received: (qmail 28320 invoked by uid 550); 12 Aug 2012 17:33:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28309 invoked from network); 12 Aug 2012 17:33:24 -0000 Content-Disposition: inline In-Reply-To: <20120812053802.GA10971@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1547 Archived-At: On Sun, Aug 12, 2012 at 01:38:02AM -0400, Rich Felker wrote: > 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. A third approach: using the nscd protocol used by glibc/nss. This would allow musl-linked binaries running as guests on glibc-based systems with nscd to perform user lookups through whatever service the host system was using, without any further configuration. The glibc nscd daemon would not be useful itself on musl-based systems, since it depends on glibc/nss, but a drop-in clone for it could easily be written and later fleshed-out with support for NIS, LDAP, and any other potentially-interesting user database backends. If folks think this third option is a good one, we'll need to dig up (or reverse engineer..?) specs on how the nscd protocol works. It might be a good idea to do this first before making a decision anyway, since if the protocol is bad enough (bloat, robustness failures, etc.) we might need to pick something else even if it does have other good qualities.. Rich