[gentoo-musl] realpath() gives wrong result on a chroot musl system

[gentoo-musl] realpath() gives wrong result on a chroot musl system

[Lei Zhang]

Hi,

I was trying to run clang (built specifically for musl) on a chroot
musl system, and met some strange issue. After some investigation, it
turns out the function realpath() is giving me wrong results.

I can reproduce the error with the following code snippet:

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>

int main(int argc, char** argv) {
    const char* path = "/usr/bin/clang"; // suppose this is a valid path
    char resolved[PATH_MAX];
    char* ret = realpath(path, resolved);

    if (ret)
        printf("%s\n", ret);
}

If I build it against musl, it gives correct result on my host, but
wrong result on chroot; If I build it against glibc (statically, since
there's no glibc on chroot), it gives correct results on both
environments. So it looks like musl is to blame on the chroot
environment. I haven't yet confirmed if it's a bug.

Any thoughts?

BTW, I built my musl system with the GRS tool, using the
desktop-amd64-musl-hardened profile.


Regards,
Lei

Re: [gentoo-musl] realpath() gives wrong result on a chroot musl system

[Anthony G. Basile]

On 6/6/16 10:11 AM, Lei Zhang wrote:
> Hi,
> 
> I was trying to run clang (built specifically for musl) on a chroot
> musl system, and met some strange issue. After some investigation, it
> turns out the function realpath() is giving me wrong results.
> 
> I can reproduce the error with the following code snippet:
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <limits.h>
> 
> int main(int argc, char** argv) {
>     const char* path = "/usr/bin/clang"; // suppose this is a valid path
>     char resolved[PATH_MAX];
>     char* ret = realpath(path, resolved);
> 
>     if (ret)
>         printf("%s\n", ret);
> }
> 
> If I build it against musl, it gives correct result on my host, but
> wrong result on chroot; If I build it against glibc (statically, since
> there's no glibc on chroot), it gives correct results on both
> environments. So it looks like musl is to blame on the chroot
> environment. I haven't yet confirmed if it's a bug.
> 
> Any thoughts?
> 
> BTW, I built my musl system with the GRS tool, using the
> desktop-amd64-musl-hardened profile.
> 
> 
> Regards,
> Lei
> 

open a bug report with steps to reproduce.  realpath is spec-ed in
POSIX.1-2001, take a look at the opengroup page for it.  also print out
the errno in case one is set.



-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-musl] realpath() gives wrong result on a chroot musl system

[Felix Janda]

Lei Zhang wrote:
> Hi,
> 
> I was trying to run clang (built specifically for musl) on a chroot
> musl system, and met some strange issue. After some investigation, it
> turns out the function realpath() is giving me wrong results.
> 
> I can reproduce the error with the following code snippet:
> 
> #include <stdio.h>
> #include <stdlib.h>
> #include <limits.h>
> 
> int main(int argc, char** argv) {
>     const char* path = "/usr/bin/clang"; // suppose this is a valid path
>     char resolved[PATH_MAX];
>     char* ret = realpath(path, resolved);
> 
>     if (ret)
>         printf("%s\n", ret);
> }
> 
> If I build it against musl, it gives correct result on my host, but
> wrong result on chroot; If I build it against glibc (statically, since
> there's no glibc on chroot), it gives correct results on both
> environments. So it looks like musl is to blame on the chroot
> environment. I haven't yet confirmed if it's a bug.
> 
> Any thoughts?

With musl, realpath() (and some other things) depend on having a
mounted /proc.

Felix

Re: [gentoo-musl] realpath() gives wrong result on a chroot musl system

[Lei Zhang]

2016-06-07 6:04 GMT+08:00 Felix Janda <felix.janda@posteo.de>:
> Lei Zhang wrote:
>> Hi,
>>
>> I was trying to run clang (built specifically for musl) on a chroot
>> musl system, and met some strange issue. After some investigation, it
>> turns out the function realpath() is giving me wrong results.
>>
>> I can reproduce the error with the following code snippet:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <limits.h>
>>
>> int main(int argc, char** argv) {
>>     const char* path = "/usr/bin/clang"; // suppose this is a valid path
>>     char resolved[PATH_MAX];
>>     char* ret = realpath(path, resolved);
>>
>>     if (ret)
>>         printf("%s\n", ret);
>> }
>>
>> If I build it against musl, it gives correct result on my host, but
>> wrong result on chroot; If I build it against glibc (statically, since
>> there's no glibc on chroot), it gives correct results on both
>> environments. So it looks like musl is to blame on the chroot
>> environment. I haven't yet confirmed if it's a bug.
>>
>> Any thoughts?
>
> With musl, realpath() (and some other things) depend on having a
> mounted /proc.

You're right!

After mounting /proc on the chroot system, the issue is resolved. At
this point I'm really not sure if this is musl's bug. Is it legit to
unconditionally depends on the presence of a mounted /proc?


Lei

Re: [gentoo-musl] realpath() gives wrong result on a chroot musl system

[Lei Zhang]

2016-06-07 8:19 GMT+08:00 Lei Zhang <zhanglei.april@gmail.com>:
> 2016-06-07 6:04 GMT+08:00 Felix Janda <felix.janda@posteo.de>:
>> Lei Zhang wrote:
>>> Hi,
>>>
>>> I was trying to run clang (built specifically for musl) on a chroot
>>> musl system, and met some strange issue. After some investigation, it
>>> turns out the function realpath() is giving me wrong results.
>>>
>>> I can reproduce the error with the following code snippet:
>>>
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <limits.h>
>>>
>>> int main(int argc, char** argv) {
>>>     const char* path = "/usr/bin/clang"; // suppose this is a valid path
>>>     char resolved[PATH_MAX];
>>>     char* ret = realpath(path, resolved);
>>>
>>>     if (ret)
>>>         printf("%s\n", ret);
>>> }
>>>
>>> If I build it against musl, it gives correct result on my host, but
>>> wrong result on chroot; If I build it against glibc (statically, since
>>> there's no glibc on chroot), it gives correct results on both
>>> environments. So it looks like musl is to blame on the chroot
>>> environment. I haven't yet confirmed if it's a bug.
>>>
>>> Any thoughts?
>>
>> With musl, realpath() (and some other things) depend on having a
>> mounted /proc.
>
> You're right!
>
> After mounting /proc on the chroot system, the issue is resolved. At
> this point I'm really not sure if this is musl's bug. Is it legit to
> unconditionally depends on the presence of a mounted /proc?

Answer from musl's mailing list: www.openwall.com/lists/musl/2016/06/07/2


Lei

[gentoo-musl] Re: realpath() gives wrong result on a chroot musl system

[Lei Zhang]

2016-06-07 2:35 GMT+08:00 Luca Barbato <lu_zero@gentoo.org>:
> On 06/06/16 16:11, Lei Zhang wrote:
>> Hi,
>>
>> I was trying to run clang (built specifically for musl) on a chroot
>> musl system, and met some strange issue. After some investigation, it
>> turns out the function realpath() is giving me wrong results.
>>
>> I can reproduce the error with the following code snippet:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <limits.h>
>>
>> int main(int argc, char** argv) {
>>     const char* path = "/usr/bin/clang"; // suppose this is a valid path
>>     char resolved[PATH_MAX];
>>     char* ret = realpath(path, resolved);
>>
>>     if (ret)
>>         printf("%s\n", ret);
>> }
>>
>> If I build it against musl, it gives correct result on my host, but
>> wrong result on chroot; If I build it against glibc (statically, since
>> there's no glibc on chroot), it gives correct results on both
>> environments. So it looks like musl is to blame on the chroot
>> environment. I haven't yet confirmed if it's a bug.
>>
>> Any thoughts?
>>
>> BTW, I built my musl system with the GRS tool, using the
>> desktop-amd64-musl-hardened profile.
>
> would help seeing the wrong results, I guess.

The return value of realpath() is NULL, and strerror(errno) is "No
such file or directory".


Lei