Date: Wed, 9 Oct 2019 05:47:49 +0200 From: Markus Wichmann <nullplan@....net> To: musl@...ts.openwall.com Subject: Re: realpath after chroot 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
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.