Re: _PATH_LASTLOG

[Rich Felker <dalias@aerifal.cx>]

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