[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Oct 2019 07:45:10 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: realpath after chroot
On Wed, Oct 09, 2019 at 05:47:49AM +0200, Markus Wichmann wrote:
> 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?
It was never optional. The fallback is for kernels that return EBADF
on O_PATH fds.
> 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.
Even after time64 there will be plenty of kernels that don't have
statx. I'm not sure when fstat stopped failing with EBADF for O_PATH.
That's the important case I'm aware of.
> fchdir() and fchown() have the same code (entering the fallback path on
> EBADF with open FD).
Right.
> So it appears that fexecve() is the exception here, entering the
> fallback path on ENOSYS.
I don't see how it's more exceptional than the others.
> > 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.
/dev is a hard POSIX dependency for /dev/null and /dev/tty, maybe
other things 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.
