From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/10103 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: realpath() depends on a mounted /proc to work Date: Wed, 8 Jun 2016 13:50:32 -0400 Message-ID: <20160608175032.GV10893@brightrain.aerifal.cx> References: <20160607011538.GU10893@brightrain.aerifal.cx> <20160607084521.08cf94ec@vostro.util.wtbts.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1465409677 19001 80.91.229.3 (8 Jun 2016 18:14:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jun 2016 18:14:37 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-10116-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jun 08 20:14:22 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1bAhcu-0006za-Mr for gllmg-musl@m.gmane.org; Wed, 08 Jun 2016 19:50:48 +0200 Original-Received: (qmail 5285 invoked by uid 550); 8 Jun 2016 17:50:45 -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 5267 invoked from network); 8 Jun 2016 17:50:45 -0000 Content-Disposition: inline In-Reply-To: <20160607084521.08cf94ec@vostro.util.wtbts.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:10103 Archived-At: On Tue, Jun 07, 2016 at 08:45:21AM +0300, Timo Teras wrote: > On Mon, 6 Jun 2016 21:15:39 -0400 > Rich Felker wrote: > > > On Tue, Jun 07, 2016 at 08:27:18AM +0800, Lei Zhang wrote: > > > Hi, > > > > > > I observed that realpath() doesn't work correctly without a mounted > > > /proc while experimenting in a chroot system, where musl is the > > > default libc. OTOH, the same program statically linked against glibc > > > worked just as expected. > > > > > > Is the dependence on a mounted /proc intentional? Then what's the > > > rationale behind it? > > > > As a whole, musl depends on having /proc; the rationale is simply that > > Linux does not expose all the functionality needed to implement POSIX > > without /proc. > > > > As for realpath, it could be done without /proc, but being that musl > > already requires /proc for full functionality, and that non-/proc > > versions of realpath are significantly heavier, more complex, and less > > reliable, simply using /proc for realpath was the natural choice. > > > > If someone wants to do a survey of what functionality actually depends > > on /proc, we could document that and also evaluate whether realpath is > > sufficiently more "basic" than other things which need /proc that we > > might want to consider having a fallback implementation for when /proc > > is missign. > > I remember we discussed this earlier, as I would prefer to have it for > running scripts in chroot from alpine package manager (without /proc). > > This would also fix applications that chroot to isolated place after > startup (e.g. some ftp servers). > > Grep says /proc is found to be used in: > - __synccall - /proc/self/task > - __procfdname - to generate /proc/self/fd/%d > - dl_iterate_phdr - /proc/self/exe as name for main executable > - dynlink - for $ORIGIN (and filtering it out from AT_EXECFN) > > __synccall is used basically for setrlimit() and set*uid(). These > generally are done in the application startup, but could become issue > in chrooted multi-threaded programs. > > And __procfdname is used in: > - ttyname_r > - realpath > - fexecve > - fchdir > - fchown > - fstat > - fchmodat > - fchmod > > For these fexecve, ttyname_r and realpath seem to unconditionally > depend on it. For the other f* fd functions it is only the fallback > code for really old kernels. This is not quite true. As of at least 3.18 or so, Linux did not support most of the f* ops (fstat, fchdir, etc.) on O_PATH file descriptors; it may still lack support. Also the Linux fchmodat syscall completely lacks the flag argument (contrary to musl's useless passing of it) so /proc is unconditionally required to support fchmodat with nonzero flag. > Given the above, I would vote realpath() to have fallback code. It's > far more widely used, and would fix several chroot usage scenarios. That seems reasonable. Fallback code should avoid using significant additional stack space and should probably only be used if the proc version fails with ENOENT (proc not mounted) and not on transient errors, so that it doesn't become a bug surface that could affect properly configured systems under low-resource conditions. > Btw, one discrepency is that ttyname_r declares: > char procname[sizeof "/proc/self/fd/" + 3*sizeof(int) + 2]; > and all other users: > char buf[15+3*sizeof(int)]; > > ttyname_r this allocates one more byte for the buffer and makes it > clear where that size comes from. Perhaps this would be good place for > some internal header that has #define and prototype for __procfdname. Yes that might be a good idea. BTW I think it's 2 more bytes, not 1. Rich