Date: Tue, 3 Dec 2013 15:25:02 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: _PATH_LASTLOG 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
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.