Date: Tue, 7 Jun 2016 08:45:21 +0300 From: Timo Teras <timo.teras@....fi> To: Rich Felker <dalias@...c.org> Cc: musl@...ts.openwall.com Subject: Re: realpath() depends on a mounted /proc to work On Mon, 6 Jun 2016 21:15:39 -0400 Rich Felker <dalias@...c.org> 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. Given the above, I would vote realpath() to have fallback code. It's far more widely used, and would fix several chroot usage scenarios. 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. Thanks, Timo
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.