Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Oct 2019 13:38:50 -0400
From: Rich Felker <>
To: Reiner Herrmann <>
Subject: Re: realpath after chroot

On Tue, Oct 08, 2019 at 07:24:02PM +0200, Reiner Herrmann wrote:
> Hi,
> I noticed that realpath is no longer working after chroot is called.
> With the example from below I get the following output with musl 1.1.23:
> # ./a.out
> /
> No such file or directory
> With glibc it is working as I would expect:
> # ./a.out
> /
> /

This is a documented requirement:

    musl aims to avoid imposing filesystem policy; however, the
    following minimal set of filesystems dependencies must be met in
    order for programs using musl to function correctly:


    - /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.


It's been discussed in more depth in other places. Basically, Linux
makes it impossible to do some things needed for a fully working
C/POSIX implementation without /proc, so we have to treat it as a
"requirement". Some subset of functionality works without it, but no
formal specification of exactly what works is made by musl.

For realpath, indeed it can be implemented in userspace without /proc,
and it may be desirable to do so as a fallback. It might make sense to
do an analysis of "how essential" /proc still is on reasonably recent
kernels; if the need for it is isolated to dynamic linker stuff (rpath
origin, etc.) then it might make a lot of sense to formalize that
/proc is only mandatory for certain things.


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.