From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) by sourceware.org (Postfix) with ESMTPS id B41FB3853578 for ; Wed, 8 Jun 2022 07:21:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B41FB3853578 Received: by mail-pj1-x1032.google.com with SMTP id a10so17807362pju.3 for ; Wed, 08 Jun 2022 00:21:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tW+BPlAfiSlGYjqWIGHRiHBb9pvafSj9uJtfLVeTTsg=; b=uHwQpYDHvcpXQh7fiKkmEPWpVKG2NnHBKnMJf3+s0nHpN6Za/8MFsgTsCYmJ/YvjrY 4dUSuEhF+2caB9PLKl64SC3w4FULg5fpYp72LBARNCjagyM4y9LyZ1MyykrdMqtTSjgm O0VbK+KPbbtW9hSUyNMS6fjiUEqAqekjHRzmo6QotQQxjLrvMUfqQF8zv6L7Gc1xKk+l TE7mdSixprPx7XUbBZ9XDEcY6h1X+PXr6AoA9KIxq2aKNCc3HUn5AN0P6pUq+PdVO7R8 /VF5/E4y1Kkp01MO7y3o266g9AA7GBfIhaSFFfQc4CnUxOXwruG4Wqv3XVp87gmLQLyb io5g== X-Gm-Message-State: AOAM532ZYECbKH1XUgOWmTzowITUghXsfvh5yY8XzUokeIZwuJL4p6jP 8jVU+rTH5/cxcdJTJoRMlZQ= X-Google-Smtp-Source: ABdhPJwpXn9ryOHIbmHAZeOhHCL5RRD+/roGlUK/OZ/m+hJxl34lknZZ7Hg8LweLHHrRnZ+lD7tlGg== X-Received: by 2002:a17:90b:1e0e:b0:1e3:2eee:3ab9 with SMTP id pg14-20020a17090b1e0e00b001e32eee3ab9mr48252844pjb.158.1654672885369; Wed, 08 Jun 2022 00:21:25 -0700 (PDT) Received: from gmail.com ([2601:600:8500:5f14:d627:c51e:516e:a105]) by smtp.gmail.com with ESMTPSA id b4-20020a1709027e0400b00164097a779fsm6233876plm.147.2022.06.08.00.21.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jun 2022 00:21:24 -0700 (PDT) Date: Wed, 8 Jun 2022 00:21:23 -0700 From: Andrei Vagin To: Florian Weimer Cc: Christian Brauner , Adhemerval Zanella , libc-alpha@sourceware.org, Alexey Izbyshev , Carlos O'Donell Subject: Re: [PATCH v4 0/3] Linux: Fix posix_spawn when user with time namespaces Message-ID: References: <20220510191155.1998575-1-adhemerval.zanella@linaro.org> <877d6tb3hl.fsf@oldenburg.str.redhat.com> <20220511092119.ke4zlm2dkazasmva@wittgenstein> <87h75dyf3p.fsf@oldenburg.str.redhat.com> <87sfori3dy.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <87sfori3dy.fsf@oldenburg.str.redhat.com> X-Spam-Status: No, score=-4.0 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Wed, 08 Jun 2022 07:21:28 -0000 On Mon, May 30, 2022 at 02:58:01PM +0200, Florian Weimer wrote: > * Andrei Vagin: > > [CLONE_NEWTIME and vfork] > > >> Breaking vfork is really a bit of a hassle for us, and the workaround > >> code is quite non-trivial and will have to implemented across many > >> projects (not just glibc). An unshare request that takes effect on > >> execve only would really help. > > > > Is the problem that vfork fails if a process has half-entered a time > > namespace? > > Exactly. Anything that implements a general-purpose process launching > facility on top of vfork now needs to implement fork fallback (after > vfork failure), so that launching processes still works if the original > process has called unshare(CLONE_NEWTIME). > > In glibc, this affects posix_spawn, but other libcs are also impacted, > and so is any custom posix_spawn-like interface that uses vfork > internally. Without fork fallback, they turn unusable if anything in > the process has previously called unshare(CLONE_NEWTIME). The fallback > implementation tends to be complicated if it's necessary to report > execve and other errors to the caller. There is a choice between the > O_CLOEXEC pipe hack (which has become more complex to implement due to > close_range support), or a shared mapping has to be created using > MAP_SHARED, and the subprocess writes error information to that (which > adds more potentially costly MM updates). MAP_SHARED is probably easier > to implement than the pipe approach (no interference possible from file > actions), but for glibc, Adhemerval wrote something based on the pipe > approach. > > But the key point is that any general-purpose wrapper around vfork now > has to implement fork fallback. > > Regarding the patch you sketched, we'd probably have to introduce a new > flag (not CLONE_NEWTIME) for this because the difference in behavior is > quite visible. I agree that if we want to switch timens on exec, we need to introduce a new clone flag. But I would like to avoid doing that. I think we can live with the current clone flag if we allow switching timens only when exec is executed by a vfork-ed process. In this case, the chance to affect existing users is very low, isn't it? Without the new change, vfork fails if the currect process has unshared timens. With the change, vfork creates a new process, and the following exec executes a binary in the target timens. Thanks, Andrei