From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14789 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: Tue, 8 Oct 2019 13:38:50 -0400 Message-ID: <20191008173850.GA16318@brightrain.aerifal.cx> References: <20191008172402.GH8814@reiner-h.de> 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="30937"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: musl@lists.openwall.com To: Reiner Herrmann Original-X-From: musl-return-14805-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 08 19:39:08 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 1iHtS0-0007v8-4B for gllmg-musl@m.gmane.org; Tue, 08 Oct 2019 19:39:08 +0200 Original-Received: (qmail 20410 invoked by uid 550); 8 Oct 2019 17:39:05 -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 20392 invoked from network); 8 Oct 2019 17:39:05 -0000 Content-Disposition: inline In-Reply-To: <20191008172402.GH8814@reiner-h.de> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14789 Archived-At: On Tue, Oct 08, 2019 at 07:24:02PM +0200, Reiner Herrmann wrote: > Hi, > > I noticed that realpath is no longer working after chroot is called. > With the example from below I get the following output with musl 1.1.23: > > # ./a.out > / > No such file or directory > > With glibc it is working as I would expect: > > # ./a.out > / > / This is a documented requirement: musl aims to avoid imposing filesystem policy; however, the following minimal set of filesystems dependencies must be met in order for programs using musl to function correctly: ... - /proc - must be a mount point for Linux procfs or a symlink to such. Several functions such as realpath, fexecve, and a number of the "at" functions added in POSIX 2008 need access to /proc to function correctly. Source: https://www.musl-libc.org/doc/1.0.0/manual.html 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. For realpath, indeed it can be implemented in userspace without /proc, and it may be desirable to do so as a fallback. 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. Rich