From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14793 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: realpath after chroot Date: Wed, 9 Oct 2019 05:47:49 +0200 Message-ID: <20191009034749.GC18139@voyager> References: <20191008172402.GH8814@reiner-h.de> <20191008173850.GA16318@brightrain.aerifal.cx> <20191008195623.GB18139@voyager> <20191008211010.GB16318@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="96237"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.9.4 (2018-02-28) To: musl@lists.openwall.com Original-X-From: musl-return-14809-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 09 05:48:05 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 1iI2xI-000OwP-N8 for gllmg-musl@m.gmane.org; Wed, 09 Oct 2019 05:48:04 +0200 Original-Received: (qmail 17723 invoked by uid 550); 9 Oct 2019 03:48:01 -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 17689 invoked from network); 9 Oct 2019 03:48:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1570592870; bh=4CmOgH9Jf8ipkOsPqSZmNDvqoLAOyz61Pilz+/xgMzM=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=ZqCzJuL2aPu1oPH32Zt162Rdyd5Ffw/5QIu1Ik1czi9/CER3cR7cUh5RyQxQBFvmA bHNngFMx0q5NMkqIiHYqeAva/g6VDocmPqm1/57rtrSMvwxFkK3HOw3PF2IistYRNi KjHqd3ZQboBm3f5q0Fa8Uwtyd8GJTBjdbuJYqz74= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Content-Disposition: inline In-Reply-To: <20191008211010.GB16318@brightrain.aerifal.cx> X-Provags-ID: V03:K1:RYEqA9EsSYmuwMV1wHvwW3/YF1IeK61m4jU3Xjk8psRa7ZJNjCR xVsExtJxwBZM0x1SobMpmzSllYralrn4UEO0X2a9Z002Kvr8aEncJFLIC2auTtKP8EbBFZv AFR31pk3p+ezoTRFPkaLiwbMbnpYBCgE/pOW3PLJHsCtX2d/cRAxZHwErfhcHh4JwwZGNCF 3pK3Y7YIAT5gh9urcRZ+w== X-UI-Out-Filterresults: notjunk:1;V03:K0:8K/NyKo6koo=:asfae9ZCGOj63S6jSzD420 oY7DFNS986SNlgqbUdPJSER2kOhjksrrxbaepsWmkpI1I+WAuOb7iXX6iTraOF4mOAgUqGRsw 13LuWLKTFWkfZeTOCwv2/TCg90cCyc4FwVORYJHmkXERfCiw8YuMa1LoqQdnC5N5jko9jpPOA l2pO60PP7yDpHpDFrfei+BOgXQd4sdaVpyJUyG8pHl9BB802ul84uXReTL4mhUy1L+GYmXgvR OhwgZ0xPZh6zDtERC5l/U4IRNuNPtxK2ydAyBcFCulMxT8GihGHAIYTuzKtUj6Ds4bsXbxsCP zXH8mDXSnHBNg7iigXouH9Hu3jY6WmCCFv8AjD/g7BlEPVpxY9BMyAQhcxu0tZZek9/3McB3v EMCE90rkVBQsxBSfhriXDMU6ovAsXzI+COA4JJmw5yFZhXDyJ2wcaIQ+aOP43OdbvKkwCIZ0i 8YiKmSm76PKOhG4+E7O1hsYwA9xEjzCrRUyPJGaIIqFN38SA6xb7YnYWX3w68S+/fEhy79U54 +2wb/8FO/r1v7x9mQ/uNX14+webgYKJpF4wAV2gHfeFwTupkI2sp/8dabpZx11heZSyzICg6R VfKYCsT3bALcDSefTeRF7Rp4d7pOr0bDu+vdOuLk7x1n9HOuHrZ6L9JH3hw7t/92dehOvCvQe TxBN8A/pNsA29C9IxWls2C2Tosu1UYg8nbsRRIuSNSjPT7OnUJ7yIasfsy/iRPyOqLgZ0kBHj 173ViyjRgoIQNSxdgSMkUmmxeGxSifNJwilwRQgA2keuAd1XEGdcGz1jm5PaOGkKzYDxLT3k Xref: news.gmane.org gmane.linux.lib.musl.general:14793 Archived-At: 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