From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14794 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: realpath after chroot Date: Wed, 9 Oct 2019 07:45:10 -0400 Message-ID: <20191009114510.GC16318@brightrain.aerifal.cx> References: <20191008172402.GH8814@reiner-h.de> <20191008173850.GA16318@brightrain.aerifal.cx> <20191008195623.GB18139@voyager> <20191008211010.GB16318@brightrain.aerifal.cx> <20191009034749.GC18139@voyager> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="186841"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14810-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 09 13:45:27 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iIAPF-000mRk-Rc for gllmg-musl@m.gmane.org; Wed, 09 Oct 2019 13:45:25 +0200 Original-Received: (qmail 13647 invoked by uid 550); 9 Oct 2019 11:45:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13629 invoked from network); 9 Oct 2019 11:45:22 -0000 Content-Disposition: inline In-Reply-To: <20191009034749.GC18139@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14794 Archived-At: 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