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.