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). 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. 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). Raphael Cohn Chief Architect, stormmq Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard raphael.cohn@stormmq.com +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 3 December 2013 19:54, Rich Felker wrote: > On Tue, Dec 03, 2013 at 07:09:05PM +0000, Raphael Cohn wrote: > > Ta. > > > > Would it be possible to have the "/dev/null/xxx" paths' values as an > option > > to ./configure? > > > > Actually, it would be very useful to be able to ./configure all the other > > hard coded paths in musl, eg the default dynamlic linker search path. > When > > running with a setup like Nixos, or the like, these paths need to be > > different. Of course, one can patch, but that's not sustainable in the > long > > run. > > The dynamic linker searches for its path file relative to its own > location, which should cover this kind of usage. It's only in the case > where no path file exists that the hard-coded /lib, /usr/lib, etc. > would get searched. > > > Please? > > I think such a request should be accompanied by explanations of what > you're trying to achieve that's difficult or impossible with the > current scheme. > > Most of the hard-coded paths in musl are hard-coded because there's a > standard pathname either required by the standards or that was > universal in all historical systems, and because musl aims to be > useful for producing "run anywhere" static binaries. Gratuitously > changing paths defeats this goal. Of course musl attempts to minimize > the number of hard-coded pathnames anyway; here's a list from the > current documentation draft which you could review to determine which > are problematic to your intended usage cases: > > ---------------------------------------------------------------------- > * `/dev/null` - device node, required by POSIX > > * `/dev/tty` - device node, required by POSIX > > * `/tmp` - required by POSIX to exist as a directory, and used by > various temporary file creation functions. > > * `/bin/sh` - an executable file providing a POSIX-conforming shell > > * `/proc` - must be a mount point for Linux procfs or a symlink to > such. Several functions such as realpath, fexecve, and a number of > the "at" functions added in POSIX 2008 need access to /proc to > function correctly. > > While some programs may operate correctly even without some or all of > the above, musl's behavior in their absence is unspecified. > > ### Additional Pathnames Used > > * `/dev/log` - a UNIX domain socket to which the `syslog()` interface > sends log messages. If absent or inaccessible, log messages will be > discarded. > > * `/dev/shm` - a directory; should have permissions 01777. If absent, > POSIX shared memory and named semaphore interfaces will fail; > programs not using these features will be unaffected. > > * `/dev/ptmx` and `/dev/pts` - device node and devpts filesystem mount > point, respectively. If absent or inaccessible, `posix_openpt()` and > `openpty()` will fail. > > * `/etc/passwd` and `/etc/group` - text files containing the user and > group databases, mappings between names and numeric ids, and group > membership lists, in the standard traditional format. If absent, > user and/or group lookups will fail. > > * `/etc/shadow` - text file containing shadow password hashes for some > or all users. > > * `/etc/resolv.conf` - text file providing addresses of nameservers to > be used for DNS lookups. If absent, DNS requests will be sent to the > loopback address and will fail unless the host has its own > nameserver. > > * `/etc/hosts` - text file mapping hostnames to IP addresses. > > * `/etc/services` - text file mapping network service names to port > numbers. > > * `/usr/share/zoneinfo`, `/share/zoneinfo`, and `/etc/zoneinfo` - > directories searched for time zone files when the `TZ` environment > variable is set to a relative pathname. > > * `../etc/ld-musl-$(ARCH).path`, taken relative to the location of the > "program interpreter" specified in the program's headers - if > present, this will be processed as a text file containing the shared > library search path, with components delimited by newlines or > colons. If absent, a default path of > `"/lib:/usr/local/lib:/usr/lib"` will be used. Not used by > static-linked programs. > ---------------------------------------------------------------------- > > Let me know. This may end up being an ugly issue but it's something we > should look at, in any case... > > Rich >