From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1549 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 16:56:43 -0400 Message-ID: <20120812205643.GT27715@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 1344804961 26770 80.91.229.3 (12 Aug 2012 20:56:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 12 Aug 2012 20:56:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1550-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 12 22:56:02 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 1T0fCR-0003Sl-E0 for gllmg-musl@plane.gmane.org; Sun, 12 Aug 2012 22:55:51 +0200 Original-Received: (qmail 24123 invoked by uid 550); 12 Aug 2012 20:55:50 -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 24115 invoked from network); 12 Aug 2012 20:55:50 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1549 Archived-At: On Sun, Aug 12, 2012 at 09:10:16PM +0200, Arvid E. Picciani wrote: > On Sun, 12 Aug 2012 01:38:02 -0400, Rich Felker wrote: > > >What I'm looking for is a way to allow musl to access user data > >that's > >not provided with flat files in /etc, > > I'm not sure why user auth is in libc in the first place. This is not auth, it's just lookups. Translating uids to usernames and back. > >[..] can query a local daemon [..] > > >The first main question is what protocol to use. > > well, so use the existing rpc. it fullfills the given requirements, > and is compatible with the stuff out there. Not an option. It's massively bloated and full of security issues. There is a legitimate need for what NIS provides, but doing it with NIS and the RPC system is backwards and stupid. Putting this backwardsness in libc just creates more cost for people who want to do it right. > >Alternatively, we could make musl speak an existing query language > >(e.g. LDAP) directly > > And pull even more policy into libc? I'm not sure how this is adding policy. I consider the other solution glibc chose, nss, to be policy. It forces your apps to have dynamic loader support in them, forces you to have config files in place and shared libraries present in hard-coded paths, etc. My intent is to minimize any such requirements, and leave them at absolute zero except for people who need giant specially-backed user databases. > Then everyone has to patch > libc to adapt to the local ldap layout? or another config? It's the intent that nobody should ever have to patch libc for the sake of accessing their user database. That's what this thread is about. I'm not familar with how LDAP is used in the wild for this purpose, or if it even is, so I don't know how easy it would be to directly interface with diverse existing LDAP servers, but it seems like it would be a reasonable, simple proxy language for lookups, whereby any customization could go in the proxy. See my later post about nscd; it might be a better choice. > There is a need for the things you want to do here, but i think > this is the line where it's time to go into higher layers. I don't follow. What alternative are your proposing? Rich