mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Raphael Cohn <raphael.cohn@stormmq.com>
To: musl@lists.openwall.com
Subject: Re: _PATH_LASTLOG
Date: Tue, 3 Dec 2013 20:10:56 +0000	[thread overview]
Message-ID: <CACCP0GqMqf2BmH+mts31_nuqLR_jzqCSLsMxSDVYSu=nk8XRwA@mail.gmail.com> (raw)
In-Reply-To: <20131203195433.GM24286@brightrain.aerifal.cx>

[-- Attachment #1: Type: text/plain, Size: 6418 bytes --]

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 <dalias@aerifal.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
>

[-- Attachment #2: Type: text/html, Size: 7600 bytes --]

  reply	other threads:[~2013-12-03 20:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-03 17:44 _PATH_LASTLOG Raphael Cohn
2013-12-03 18:42 ` _PATH_LASTLOG Szabolcs Nagy
2013-12-03 19:09   ` _PATH_LASTLOG Raphael Cohn
2013-12-03 19:54     ` _PATH_LASTLOG Rich Felker
2013-12-03 20:10       ` Raphael Cohn [this message]
2013-12-03 20:25         ` _PATH_LASTLOG Rich Felker
2013-12-03 20:44           ` _PATH_LASTLOG Laurent Bercot
2013-12-03 20:51             ` _PATH_LASTLOG Raphael Cohn
2013-12-03 21:00               ` _PATH_LASTLOG Nathan McSween
2013-12-03 21:05                 ` _PATH_LASTLOG Raphael Cohn
2013-12-03 21:42                 ` _PATH_LASTLOG Rich Felker
2013-12-03 21:38             ` _PATH_LASTLOG Rich Felker
2013-12-03 20:49           ` _PATH_LASTLOG Raphael Cohn
2013-12-03 20:51         ` _PATH_LASTLOG Laurent Bercot
2013-12-03 20:52           ` _PATH_LASTLOG Raphael Cohn
2013-12-03 19:34 ` _PATH_LASTLOG Rich Felker
2013-12-03 19:50   ` _PATH_LASTLOG Raphael Cohn
2013-12-03 20:03     ` _PATH_LASTLOG Laurent Bercot
2013-12-03 20:11       ` _PATH_LASTLOG Raphael Cohn
2013-12-03 20:06     ` _PATH_LASTLOG Rich Felker
2013-12-03 20:18       ` _PATH_LASTLOG Raphael Cohn
2013-12-03 20:30         ` _PATH_LASTLOG Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACCP0GqMqf2BmH+mts31_nuqLR_jzqCSLsMxSDVYSu=nk8XRwA@mail.gmail.com' \
    --to=raphael.cohn@stormmq.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).