Re: realpath after chroot

[Markus Wichmann <nullplan@gmx.net>]

On Tue, Oct 08, 2019 at 05:10:10PM -0400, Rich Felker wrote:
> On Tue, Oct 08, 2019 at 09:56:23PM +0200, Markus Wichmann wrote:
> > 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.
>

Yes, I just had a glance at the code. For fchmod(), the fallback path is
triggered if SYS_fchmod returned EBADF, and yet the file descriptor
flags could be retrieved, indicating the FD is open. I'm guessing
SYS_fchmod is no longer an optional system call, but is bad about
O_PATH?

fstatat() is really special. There is the SYS_statx codepath which is
ignored on most architectures. At least until you push the time64_t
stuff. And __procfdname() is only called in the AT_EMPTY_PATH case, if
SYS_fstat displayed the same behavior as above (returning EBADF on an
open FD), and SYS_fstatat failed with EINVAL.

fchdir() and fchown() have the same code (entering the fallback path on
EBADF with open FD).

So it appears that fexecve() is the exception here, entering the
fallback path on ENOSYS.

> 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.
>

I was about to protest that this would add /dev to the list of
dependencies. Then I noticed that ttyname() tries to stat() its result,
so if /dev isn't in the chroot jail, it does not work, either.

Ciao,
Markus