Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 13 Sep 2022 04:37:33 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Andrei Vagin <avagin@google.com>
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Revert "fs/exec: allow to unshare a time namespace
 on vfork+exec"
Message-ID: <202209130435.12231CE199@keescook>
References: <20220913102551.1121611-1-avagin@google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220913102551.1121611-1-avagin@google.com>
Precedence: bulk

On Tue, Sep 13, 2022 at 03:25:49AM -0700, Andrei Vagin wrote:
> This reverts commits:
> 133e2d3e81de ("fs/exec: allow to unshare a time namespace on vfork+exec")
> 6342140db660 ("selftests/timens: add a test for vfork+exit")
> 
> Alexey pointed out a few undesirable side effects of the reverted change.
> First, it doesn't take into account that CLONE_VFORK can be used with
> CLONE_THREAD. Second, a child process doesn't enter a target time name-space,
> if its parent dies before the child calls exec. It happens because the parent
> clears vfork_done.
> 
> Eric W. Biederman suggests installing a time namespace as a task gets a new mm.
> It includes all new processes cloned without CLONE_VM and all tasks that call
> exec(). This is an user API change, but we think there aren't users that depend
> on the old behavior.

Can we include that patch here as well?

> It is too late to make such changes in this release, so let's roll back
> this patch and introduce the right one in the next release.

Do you mean you'd like this revert to land for v6.0, and we should wait
for the new API for later?

-- 
Kees Cook