[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191008211010.GB16318@brightrain.aerifal.cx>
Date: Tue, 8 Oct 2019 17:10:10 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: realpath after chroot
On Tue, Oct 08, 2019 at 09:56:23PM +0200, Markus Wichmann wrote:
> 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
Thanks for working these out.
For the ones marked "fallback path", it's not entirely clear whether
the fallback path is only needed for old kernels, or possibly needed
even on recent/current ones. Historically Linux was very sloppy about
supporting some of these operations on O_PATH (used for
O_EXEC/O_SEARCH) fds.
> 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.
And possibly others (see above).
> > 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.
Perhaps; I'd have to think more about whether this is actually a
problem.
> Another might be name or path size limits (maybe a future
> kernel no longer enforces them).
Regardless of whether kernel enforces PATH_MAX, we do. It's a feature.
So I don't think this is a problem.
> > 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.
Indeed, there are at least a few items of "standard functionality"
that depend on /proc, regardless of the status of the "fallback" ones:
at least ttyname and fchmodat. Note that ttyname can be done without
/proc by searching /dev for matching dev_t, either using known
patterns for tty names or a global search, but this is ugly too.
Rich
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.
