From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4339 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: _PATH_LASTLOG Date: Tue, 3 Dec 2013 15:25:02 -0500 Message-ID: <20131203202502.GO24286@brightrain.aerifal.cx> References: <20131203184248.GT1685@port70.net> <20131203195433.GM24286@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: ger.gmane.org 1386102309 17382 80.91.229.3 (3 Dec 2013 20:25:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2013 20:25:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4343-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 03 21:25:15 2013 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 1VnwWx-0007QU-Fe for gllmg-musl@plane.gmane.org; Tue, 03 Dec 2013 21:25:15 +0100 Original-Received: (qmail 15449 invoked by uid 550); 3 Dec 2013 20:25:15 -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 15441 invoked from network); 3 Dec 2013 20:25:14 -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:4339 Archived-At: On Tue, Dec 03, 2013 at 08:10:56PM +0000, Raphael Cohn wrote: > Thanks for that - just having a list is an useful place to start. I think > the default file names are quite sensible - especially for a common > run-anywhere use case. And some - where mandated by POSIX - probably should > never change. What would be nice might be to be able to define the prefix > for /etc to something else (so we can use atomic symlink changes to flip > configs). Are you also talking about having separate configuration dirs for each package? Would each package need its own user database (passwd file), DNS configuration (which the DHCP client would have to update), etc.? The intent in musl is that the "config"-like files it reads from /etc are not things that should be application-local but system-global. Obviously there are different views on what's local/global, though. One problem I'd like to solve is making a way for users to override the system resolv.conf; this would be especially valuable for us (musl developers) writing test cases for the resolver, in that we could redirect lookups to a fake DNS daemon running in a separate thread of the test program serving fixed, possibly-intentionally-malformed replies. > I'd like to have more of a think about the other paths. We're only a short > way into our project, so our ideas might change. What we're looking at is a > Nixos-like linux, where we rebuild only packages because other packages > have changed. We want to keep every package isolated, so we can apply PATH > controls, fine-grained capability permissions, chattr -ai, etc. Part of > doing this means we don't want paths 'hanging around' inside libraries that > are used if present - as these allow an attacker (or more likely, a duff > package) to accidentally stop itself working, ie if there's no /usr/lib on > system, then nothing should be able to stick itself in /usr/lib and > override the system setup. This seems like a good foundation for a package system. I've looked into Nixos before but never really tried it out, and got the impression that the concept was very good but it might not be the best implementation. So something similar to Nixos sounds interesting. :-) > PS As an aside, I've always wanted /etc/hosts to also have a parallel > /etc/hosts.d/. It'd make maintaining things without a DNS server extremely > easy - think dynamically adding and removing VMs in most cloud providers, > especially those where multicast DNS doesn't work... like Azure. (Yes, I > had a client that insisted on using it with Linux). Likewise it'd be nice > to be able to add and remove DNS servers with a /etc/resolv.conf.d. Makes > automated config and change management and audit that bit easier. (Debian > do this using run-parts for lots of things for those sorts of reasons). The philosophy used in musl, which is somewhat different from the sort of philosophy you might have when designing a new distribution, is not to invent new policy but to avoid policy and build on existing, already-widely-accepteed policy when it's unavoidable. There are LOTS of ways one could extend hostname lookups, ranging from NSS modules to hosts.d and resolv.d, but rather than trying to support everything imaginable (result: bloat and serious security considerations) in libc, the musl approach to hostname lookup is that libc contains the basics that are suitable for most/all simple systems, and anything more advances can be provided by an external daemon running on localhost that speaks DNS protocol and provides whatever lookup semantics you desire. Rich