From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 45C433858403 for ; Sun, 29 Aug 2021 16:57:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 45C433858403 Received: by mail-pl1-x629.google.com with SMTP id bg1so1855510plb.13 for ; Sun, 29 Aug 2021 09:57:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ausd8rcLUc0qfg/ICSyk0ocvTTnJ90g1HgBaFdIo28k=; b=aFJPJ8n7YiUALVCiw1t0RmvSzMO1s6Xd02vCI/UF1lOnp9SgfypaGP5vngokgxheWQ IT4JZW2l2oBa+Pa+pwDVCzWFd871u/yyepuZM3UKnZCneJEz/oQPVjHLEwLwacAQb2QH q+FKG+fcHgY5hraRKeif5jIet20A+ZRzQbR3RJOknh4OE9lEQiom2qhPExmG+uGUEAFs vvcTzYcd/GT3Oe+2kOU2sMK6WBDPiX4DiULfV0GunueOdRNsKq6+zd1WsZ0vH6s0UeVL Tkir2ColvegEtM9jYvrQGmh4r9ZumUGjaUE6crzTlEAzK4r0dB2YQnJ8XPu2QWMYw5Yk eJfQ== X-Gm-Message-State: AOAM533tnf9mBNtJDeJvFOBhwqC7XoTxTBsy3kbjwErVaXw2KxOjN2FI yJmoW14S9wMHKLtR7INknA/1acthtjgYISSXnsc= X-Google-Smtp-Source: ABdhPJyRAnw8e6lDq51vhCUIMUnq2NvWuZYS0RlEDmyaPbtgxHfl+WfpPkG/P2KFRY23cX7OHpSXme4cVCD5wCYLqqo= X-Received: by 2002:a17:90b:f03:: with SMTP id br3mr9275892pjb.136.1630256259156; Sun, 29 Aug 2021 09:57:39 -0700 (PDT) MIME-Version: 1.0 References: <20210829132954.18148-1-hongxu.jia@windriver.com> <1c9b4070-e2dd-444e-2007-0102702cb090@windriver.com> In-Reply-To: From: "H.J. Lu" Date: Sun, 29 Aug 2021 09:57:03 -0700 Message-ID: Subject: Re: [PATCH] fix create thread failed in unprivileged process [BZ #28287] To: Hongxu Jia Cc: GNU C Library , Adhemerval Zanella , Richard Purdie Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3024.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2021 16:57:41 -0000 On Sun, Aug 29, 2021 at 9:03 AM Hongxu Jia wrote: > > 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 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 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 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 > > Someone needs to add it. -- H.J.