From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1568 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: Mon, 13 Aug 2012 15:50:32 -0400 Message-ID: <20120813195032.GZ27715@brightrain.aerifal.cx> References: <20120812053802.GA10971@brightrain.aerifal.cx> <20120812205643.GT27715@brightrain.aerifal.cx> <20120813135048.GX27715@brightrain.aerifal.cx> <20120813192833.GY27715@brightrain.aerifal.cx> <58cedf3a99d2a7eb61d861abdb8c1840@exys.org> 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 1344887379 14331 80.91.229.3 (13 Aug 2012 19:49:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Aug 2012 19:49:39 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1569-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 13 21:49:37 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 1T10ds-0006Kq-Ng for gllmg-musl@plane.gmane.org; Mon, 13 Aug 2012 21:49:36 +0200 Original-Received: (qmail 32251 invoked by uid 550); 13 Aug 2012 19:49:35 -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 32243 invoked from network); 13 Aug 2012 19:49:35 -0000 Content-Disposition: inline In-Reply-To: <58cedf3a99d2a7eb61d861abdb8c1840@exys.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1568 Archived-At: On Mon, Aug 13, 2012 at 09:38:57PM +0200, Arvid E. Picciani wrote: > On Mon, 13 Aug 2012 15:28:33 -0400, Rich Felker wrote: > > >It reads it because ls -l prints the owners of files, and seeing a > >username rather than a number is a lot more informative. > > Oh yeah. Now it would be really horrible to have it build up an ldap > connection each time you do "ls". People do that in tight loops in > scripts > and expect it to have semi-guaranteed runtime properties. It only does the lookup with -l, and good implementations of ls will cache the last user lookup (or maybe the last N for some large value of N) to avoid being slow. Keep in mind, even without any remote query, getpwuid_r has to parse the entire /etc/passwd file every time it's called, which is not fast, so apps have a good reason to be doing caching already. glibc has a solution for this problem in the form of nscd, one of the other solutions I proposed. It's a daemon whose purpose was just to cache lookup results, but since the lookups are performed in the daemon rather than the client, it could also be used as a translating proxy to add support for arbitrary backends/protocols. I have no idea how ugly the nscd protocol is, but if it's clean, I think we could simply adopt it. musl-native systems would of course need a new nscd (since the original one is part of glibc and depends on the libnss mess) but musl binaries running on glibc systems could even use the existing host nscd. Anyway, to determine if this solution makes sense, somebody needs to do a bit of research into the nscd protocol and how bad it is... > Can we at least have compile-time modules for this, so a > system-designer > can choose between different implementations? Maybe then having ldab > in there > directly isn't so bad at all. Hidding away the ldap problems in another > daemon sounds like an attempt to make a one-size-fits-all. The problem with this is when you copy or static-linked busybox onto a system that needs non-flat-file user lookups, and it fails to work right... I'm actually interesting in making _some_ features in musl compile-time switchable, but only when they have a large size impact that would affect really tiny embedded usage. The only examples that come to mind so far are iconv charsets and crypt hashes. And in this case, the option would not be to remove the interfaces entirely, only to remove support for unneeded charsets (in the case of iconv) or unneeded hashes (in the case of crypt). I don't think removing ~50 lines of passwd entry lookup code would be of much benefit for cutting down size, whereas every switch is an addtional complexity cost (e.g. for cases that must be tested). Rich