[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160607084521.08cf94ec@vostro.util.wtbts.net>
Date: Tue, 7 Jun 2016 08:45:21 +0300
From: Timo Teras <timo.teras@....fi>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: realpath() depends on a mounted /proc to work
On Mon, 6 Jun 2016 21:15:39 -0400
Rich Felker <dalias@...c.org> wrote:
> On Tue, Jun 07, 2016 at 08:27:18AM +0800, Lei Zhang wrote:
> > Hi,
> >
> > I observed that realpath() doesn't work correctly without a mounted
> > /proc while experimenting in a chroot system, where musl is the
> > default libc. OTOH, the same program statically linked against glibc
> > worked just as expected.
> >
> > Is the dependence on a mounted /proc intentional? Then what's the
> > rationale behind it?
>
> As a whole, musl depends on having /proc; the rationale is simply that
> Linux does not expose all the functionality needed to implement POSIX
> without /proc.
>
> As for realpath, it could be done without /proc, but being that musl
> already requires /proc for full functionality, and that non-/proc
> versions of realpath are significantly heavier, more complex, and less
> reliable, simply using /proc for realpath was the natural choice.
>
> If someone wants to do a survey of what functionality actually depends
> on /proc, we could document that and also evaluate whether realpath is
> sufficiently more "basic" than other things which need /proc that we
> might want to consider having a fallback implementation for when /proc
> is missign.
I remember we discussed this earlier, as I would prefer to have it for
running scripts in chroot from alpine package manager (without /proc).
This would also fix applications that chroot to isolated place after
startup (e.g. some ftp servers).
Grep says /proc is found to be used in:
- __synccall - /proc/self/task
- __procfdname - to generate /proc/self/fd/%d
- dl_iterate_phdr - /proc/self/exe as name for main executable
- dynlink - for $ORIGIN (and filtering it out from AT_EXECFN)
__synccall is used basically for setrlimit() and set*uid(). These
generally are done in the application startup, but could become issue
in chrooted multi-threaded programs.
And __procfdname is used in:
- ttyname_r
- realpath
- fexecve
- fchdir
- fchown
- fstat
- fchmodat
- fchmod
For these fexecve, ttyname_r and realpath seem to unconditionally
depend on it. For the other f* fd functions it is only the fallback
code for really old kernels.
Given the above, I would vote realpath() to have fallback code. It's
far more widely used, and would fix several chroot usage scenarios.
Btw, one discrepency is that ttyname_r declares:
char procname[sizeof "/proc/self/fd/" + 3*sizeof(int) + 2];
and all other users:
char buf[15+3*sizeof(int)];
ttyname_r this allocates one more byte for the buffer and makes it
clear where that size comes from. Perhaps this would be good place for
some internal header that has #define and prototype for __procfdname.
Thanks,
Timo
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.
