From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: realpath after chroot
Date: Tue, 8 Oct 2019 21:56:23 +0200 [thread overview]
Message-ID: <20191008195623.GB18139@voyager> (raw)
In-Reply-To: <20191008173850.GA16318@brightrain.aerifal.cx>
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
next prev parent reply other threads:[~2019-10-08 19:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 17:24 Reiner Herrmann
2019-10-08 17:38 ` Rich Felker
2019-10-08 17:49 ` Reiner Herrmann
2019-10-08 19:56 ` Markus Wichmann [this message]
2019-10-08 21:10 ` Rich Felker
2019-10-09 3:47 ` Markus Wichmann
2019-10-09 11:45 ` Rich Felker
2019-10-09 16:00 ` Markus Wichmann
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=20191008195623.GB18139@voyager \
--to=nullplan@gmx.net \
--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).