From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14791 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: Tue, 8 Oct 2019 21:56:23 +0200 Message-ID: <20191008195623.GB18139@voyager> References: <20191008172402.GH8814@reiner-h.de> <20191008173850.GA16318@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="81657"; 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-14807-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 08 21:56:39 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 1iHvb5-000L9H-6j for gllmg-musl@m.gmane.org; Tue, 08 Oct 2019 21:56:39 +0200 Original-Received: (qmail 1694 invoked by uid 550); 8 Oct 2019 19:56:36 -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 1676 invoked from network); 8 Oct 2019 19:56:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1570564584; bh=6nM8zEnNIb3hIlgmK2kDJeXKyX3E57jayimgxFCJyME=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=hdIxU439xqYSM6YwP7xGFtIB/zM+JoAPB7p5FM1DhVK+ZllBwi212A3UqYdPyVGv8 OBodC6KtRGIk9WEPui1+MLyDK4IJgBQiyxWFHWRFRjYSusqNK0gN8Q71vQemNfqOEa p8Z4KDB7Y4jBBx5u67/XabZCpLJyc1Y+Iy+fvWAs= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Content-Disposition: inline In-Reply-To: <20191008173850.GA16318@brightrain.aerifal.cx> X-Provags-ID: V03:K1:do53qY/TxO+L+tpeYotGx75I0RBcP4nX9EaXUQpYdd9DKkyLL/T ysY5bF+FF3DBiPYdOsXPXIis8+C4ARnwyhw0OnPrAaYGXB52F+MzwX2HAWUa4BDUE7fxyLM aNZbUPnB0CUflW5Ejwl6pRLTv810HBU3KJnV5QMZqyJsqtYg7XoJxTGJhq6NIi/o8Vyl7KU UyDngORoUnRTgKOLmoKcQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:vg/ttChBHAo=:qVEk8pg2sDyVKhQ5QFmtRo 0I+nFarTP82jakUoeyRtP4XE1AyuSbGAlS02+Vr8hqKSLjTqfkaISn/oB7VC2rusVms2Tcm51 wJtXwEsO4230t7SUFU1RoCJ7I2oI3v24r8/UukYv6c9dCprP8XBFEkm73zGHGjgB71k9Emy5Z L56U3vjpE+hvU7YNl0teHqu4ZgebLikx+X3aro2JkEP0ihZFAUG9PToKO/cg2DsfqtEMl0dxm 8jBw4AYGlIQoYTOC9dM8p03Tl2+LhDGVeg13xHljIj5aTMlmiI/Xlp1TpCqjAgjzyZjJkgFJJ aHp+ymCy+xRxymCxGi08JpjdKxmpEjtvS0Zw3plkabuPjXV+eRcyZOYibsWb9fl46JWJHRzBg puS9XoNxVd3kdD4M8c1xjs5Hs3VXSWQnCDbSAu6hIQDOcueT7UVHnF8zMaMJCTJ7QI04l70/S m1pi3kOJbxYUfCn+i4Jf+QgmcDMs9rDVO3ux+9fPy3KKx88X8yyBrmqZFHnLeMrKtZUM1Nhns bXfjagEt6QgUt0U8FGfl6SOZ8IUanabluaFU35YAZHwMCV7aixvXpAi0KIsWLD/PgJaEDWXdT +bf7sliXy8MQzj8zHMlj94KmNqB5pBd1OdN2RY2chfMbgBy46vGbDtHbAIQjIzsyM0JrCNUiV BfDqI5f1dvxFpPYrpJxXhRNt24mcdrdCKVOK06/3edxns7ATIvOraKYaZu21A9dNhtadGZot4 CI+MOc/OgRX7lsMQfjwSvQmnKTBMWffdsRYidUsUCHo1oFiSWKPAMrkAI3n6eU+jkq22xPk4 Xref: news.gmane.org gmane.linux.lib.musl.general:14791 Archived-At: On Tue, Oct 08, 2019 at 01:38:50PM -0400, Rich Felker wrote: > It's been discussed in more depth in other places. Basically, Linux > makes it impossible to do some things needed for a fully working > C/POSIX implementation without /proc, so we have to treat it as a > "requirement". Some subset of functionality works without it, but no > formal specification of exactly what works is made by musl. > 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 Besides that, the dynlinker tries to find $ORIGIN by means of /proc/self/exe, the static version of dl_iterate_phdr() uses the same file name as executable file name (does that count as a "use"?), and of course pthread_setname_np() tries to write to /proc/self/task//comm. So, on a recent enough kernel, only realpath(), ttyname(), pthread_setname_np() and some fchmodat() calls remain. > For realpath, indeed it can be implemented in userspace without /proc, > and it may be desirable to do so as a fallback. The only algorithm I can think of for this is to implement path_resolution(7). Which I did once (to see if I could), and it was a lot of code. But it boils down to calling lstat() on every single path component, and then readlink(), as necessary. Personally, I dislike that, because you have to implement something that already happens in the kernel, but now outside the kernel. With the same algorithm present in two places, it is likely that they will diverge. One point of disagreement might be the number of symlinks required to return ELOOP. Another might be name or path size limits (maybe a future kernel no longer enforces them). > It might make sense to > do an analysis of "how essential" /proc still is on reasonably recent > kernels; if the need for it is isolated to dynamic linker stuff (rpath > origin, etc.) then it might make a lot of sense to formalize that > /proc is only mandatory for certain things. See above, though I don't know if you want to formalize that. Ciao, Markus