[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191008195623.GB18139@voyager>
Date: Tue, 8 Oct 2019 21:56:23 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: realpath after chroot
On Tue, Oct 08, 2019 at 01:38:50PM -0400, Rich Felker wrote:
> 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.
>
Well, what does depend on /proc at the moment? Of course, there is
everything calling __procfdname(), so that would be
- realpath() (main path)
- fexecve() (fallback path)
- fchmod() (fallback path)
- fchmodat() (main path for AT_SYMLINK_NOFOLLOW)
- fstatat() (fallback path)
- fchdir() (fallback path)
- fchown() (fallback path)
- ttyname_r() (main path), and ttyname() by extension
Besides that, the dynlinker tries to find $ORIGIN by means of
/proc/self/exe, the static version of dl_iterate_phdr() uses the same
file name as executable file name (does that count as a "use"?), and of
course pthread_setname_np() tries to write to
/proc/self/task/<tid>/comm.
So, on a recent enough kernel, only realpath(), ttyname(),
pthread_setname_np() and some fchmodat() calls remain.
> For realpath, indeed it can be implemented in userspace without /proc,
> and it may be desirable to do so as a fallback.
The only algorithm I can think of for this is to implement
path_resolution(7). Which I did once (to see if I could), and it was a
lot of code. But it boils down to calling lstat() on every single path
component, and then readlink(), as necessary.
Personally, I dislike that, because you have to implement something that
already happens in the kernel, but now outside the kernel. With the same
algorithm present in two places, it is likely that they will diverge.
One point of disagreement might be the number of symlinks required to
return ELOOP. Another might be name or path size limits (maybe a future
kernel no longer enforces them).
> 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.
See above, though I don't know if you want to formalize that.
Ciao,
Markus
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.
