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

["H.J. Lu" <hjl.tools@gmail.com>]

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?

-- 
H.J.