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.