[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Dec 2013 20:10:56 +0000
From: Raphael Cohn <raphael.cohn@...rmmq.com>
To: musl@...ts.openwall.com
Subject: Re: _PATH_LASTLOG
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@...rmmq.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 <dalias@...ifal.cx> 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
>
Content of type "text/html" skipped
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.
