Re: [PATCH] fix create thread failed in unprivileged process [BZ #28287]

[Hongxu Jia <hongxu.jia@windriver.com>]

On 8/29/21 11:20 PM, H.J. Lu wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On Sun, Aug 29, 2021 at 7:50 AM Hongxu Jia <hongxu.jia@windriver.com> wrote:
>> On 8/29/21 10:43 PM, H.J. Lu wrote:
>>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>>
>>> On Sun, Aug 29, 2021 at 7:12 AM Hongxu Jia <hongxu.jia@windriver.com> wrote:
>>>> On 8/29/21 9:47 PM, H.J. Lu wrote:
>>>>> [Please note: This e-mail is from an EXTERNAL e-mail address]
>>>>>
>>>>> On Sun, Aug 29, 2021 at 6:29 AM Hongxu Jia <hongxu.jia@windriver.com> wrote:
>>>>>> Since commit [d8ea0d0168 Add an internal wrapper for clone, clone2 and clone3]
>>>>>> applied, start a unprivileged container (docker run without --privileged),
>>>>>> it creates a thread failed in container.
>>>>>>
>>>>>> In commit d8ea0d0168, it calls __clone3 if HAVE_CLONE3_WAPPER is defined.  If
>>>>>> __clone3 returns -1 with ENOSYS, fall back to clone or clone2.
>>>>>>
>>>>>> As known from [1], cloneXXX fails with EPERM if CLONE_NEWCGROUP,
>>>>>> CLONE_NEWIPC, CLONE_NEWNET, CLONE_NEWNS, CLONE_NEWPID, or CLONE_NEWUTS
>>>>>> was specified by an unprivileged process (process without CAP_SYS_ADMIN)
>>>>> I don't think the description is accurate.  In your test, none
>>>>> of the mentioned flags are used directly.  The real bug is
>>>>> that the container you used blocks the normal clone3 and
>>>>> sets errno to EPERM.  The question is if/how glibc should
>>>>> work arounds the clone3 bug in containers.   We want to add
>>>>> a public clone3 wrapper to glibc in the future.  But before we
>>>>> do that, all these containers should be changed to ENOSYS
>>>>> if clone3 is blocked.
>>>> You mean I should fix the container (here is the docker I used) to correct
>>>> EPERM to ENOSYS in this situation, but for the released/old docker,
>>>> the pthread_create still does not work with glibc 2.34 in unprivileged mode.
>>>>
>>>> In other word, should the new glibc consider backward compatibility with
>>>> others?
>>> I don't think we should hide the container bug in glibc.   Will a glibc tunable
>>> to disable the clone3 wrapper work here?
>> Yes, that's my plan B, disable it by removing the macro definition of
>> HAVE_CLONE3_WRAPPER in our Yocto's glibc
>>
> This is an option.  But this is not what I meant.  We can add
>
> $ export GLIBC_TUNABLES=glibc.syscall=disable_clone3
>
> to disable the clone3 wrapper.

Thank you very much, setting an environment is better than applying an 
patch to sources

but unfortunately, I set 'export 
GLIBC_TUNABLES=glibc.syscall=disable_clone3' in my glibc build 
environment, but it seems not work,

the issue still exists. I also apply it in my runtime container, it does 
not work neither.

My build environment is a Yocto project that supports cross compiling, I 
am not familiar with GLIBC_TUNABLES setting,

with a simple search in glibc sources, I do not find clues about 
glibc.syscall=disable_clone3

//Hongxu

//


>
> --
> H.J.