From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) by sourceware.org (Postfix) with ESMTPS id 4275C3858403 for ; Sun, 29 Aug 2021 15:20:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4275C3858403 Received: by mail-pj1-x1030.google.com with SMTP id u13-20020a17090abb0db0290177e1d9b3f7so12129151pjr.1 for ; Sun, 29 Aug 2021 08:20:38 -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=FugWZrxI4C2PNvK7TrCMTHZwBLtpDaEiMx8HVmlCA0k=; b=LR12carWsoETiTKrwpV2QZ5HP9BA9Jdwct91YMsDaIFt0dlIpm4n7s8ucj169OuC+5 1qq6/77WnPjaDQfZYaqsmUkAKAzBj1TloGk/IeUZ7yXhLIwZEzSn4bw5Y4iOn6jrnJNd HyQ/1lEUml9D/3NjG67ruBl5IE3/i5jkvxQWCOm6Bai4/QlGp3apnuIbfsE60gaiQwTG SWH57d2QT/BPYQOfSwMFvweDxrCUn4vwTGLBx60saliBwBGAx87GwMjpSgxbBBHsgjOK BZkfwuhgshviXscYtOBIBlIfbZKVuDzgDBHrpLsGC4cNazrpq2qoNYFk0Qfb9CnC+fet al9Q== X-Gm-Message-State: AOAM5330HGl7HllhAQs4p5uIfRUa0DchaI/2LVsPyPLvr8vsiK5G33MP XIyNHLuaiByUSnqLwlXY3u93X4brZe9PsijYBcybnQXDgAk= X-Google-Smtp-Source: ABdhPJy6grjQgfH2ZjuSGUHuHT4y66fQLtm5Z/g5Y7TtYS13gDpM/VGdJDFYwb+FyI/Lq+g5XFyEaP5VD9/qtil/5Vk= X-Received: by 2002:a17:90b:f03:: with SMTP id br3mr8914902pjb.136.1630250437185; Sun, 29 Aug 2021 08:20:37 -0700 (PDT) MIME-Version: 1.0 References: <20210829132954.18148-1-hongxu.jia@windriver.com> <1c9b4070-e2dd-444e-2007-0102702cb090@windriver.com> In-Reply-To: <1c9b4070-e2dd-444e-2007-0102702cb090@windriver.com> From: "H.J. Lu" Date: Sun, 29 Aug 2021 08:20:01 -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.4 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 15:20:42 -0000 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. -- H.J.