Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 3 Nov 2016 18:03:21 +0100
From: Quentin Rameau <>
Subject: Re: realpath() depends on a mounted /proc to work


> > > > 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.
> > 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.

I encountered the same issue and after finding this thread I decided to
have a go at implementing a naive realpath fallback.

I tried to follow the coding style of what I saw in musl but I'm not
sure which approach would be preferred so I joint two patches to this
mail, first using pointers, second using array indexes.

I'll gladly rework on this first batch if you're interested in it but
not satisfied yet with it.


View attachment "0001-realpath-add-fallback-processing-without-proc_pointers.patch" of type "text/plain" (2620 bytes)

View attachment "0001-realpath-add-fallback-processing-without-proc_arrays.patch" of type "text/plain" (2583 bytes)

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.