public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Andrei Vagin <avagin@google.com>
Cc: linux-kernel@vger.kernel.org, Andrei Vagin <avagin@gmail.com>,
	Alexey Izbyshev <izbyshev@ispras.ru>,
	Christian Brauner <brauner@kernel.org>,
	Dmitry Safonov <0x7f454c46@gmail.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Florian Weimer <fweimer@redhat.com>
Subject: Re: [PATCH 1/2] fs/exec: switch timens when a task gets a new mm
Date: Wed, 21 Sep 2022 20:29:21 -0700	[thread overview]
Message-ID: <202209212028.0C060F98@keescook> (raw)
In-Reply-To: <20220921003120.209637-1-avagin@google.com>

On Tue, Sep 20, 2022 at 05:31:19PM -0700, Andrei Vagin wrote:
> From: Andrei Vagin <avagin@gmail.com>
> 
> Changing a time namespace requires remapping a vvar page, so we don't want
> to allow doing that if any other tasks can use the same mm.
> 
> Currently, we install a time namespace when a task is created with a new
> vm. exec() is another case when a task gets a new mm and so it can switch
> a time namespace safely, but it isn't handled now.
> 
> One more issue of the current interface is that clone() with CLONE_VM isn't
> allowed if the current task has unshared a time namespace
> (timens_for_children doesn't match the current timens).
> 
> Both these issues make some inconvenience for users. For example, Alexey
> and Florian reported that posix_spawn() uses vfork+exec and this pattern
> doesn't work with time namespaces due to the both described issues.
> LXC needed to workaround the exec() issue by calling setns.
> 
> In the commit 133e2d3e81de5 ("fs/exec: allow to unshare a time namespace on
> vfork+exec"), we tried to fix these issues with minimal impact on UAPI. But
> it adds extra complexity and some undesirable side effects. Eric suggested
> fixing the issues properly because here are all the reasons to suppose that
> there are no users that depend on the old behavior.
> 
> Cc: Alexey Izbyshev <izbyshev@ispras.ru>
> Cc: Christian Brauner <brauner@kernel.org>
> Cc: Dmitry Safonov <0x7f454c46@gmail.com>
> Cc: "Eric W. Biederman" <ebiederm@xmission.com>
> Cc: Florian Weimer <fweimer@redhat.com>
> Cc: Kees Cook <keescook@chromium.org>
> Suggested-by: "Eric W. Biederman" <ebiederm@xmission.com>
> Origin-author: "Eric W. Biederman" <ebiederm@xmission.com>
> Signed-off-by: Andrei Vagin <avagin@gmail.com>

This looks good -- my intention is for this to go into -next after the
v6.1 merge window closes. Does that match everyone's expectations?

Thanks!

-Kees

-- 
Kees Cook

  parent reply	other threads:[~2022-09-22  3:33 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21  0:31 [PATCH 1/2] fs/exec: switch timens when a task gets a new mm Andrei Vagin
2022-09-21  0:31 ` [PATCH 2/2] selftests/timens: add a test for vfork+exit Andrei Vagin
2022-10-09 16:10   ` Alexey Izbyshev
2022-10-13 17:46     ` Andrei Vagin
2022-10-13 22:15       ` Alexey Izbyshev
2022-10-13 17:31   ` [PATCH 2/2 v2] " Andrei Vagin
2022-09-22  3:29 ` Kees Cook [this message]
2022-09-23  1:47   ` [PATCH 1/2] fs/exec: switch timens when a task gets a new mm Andrei Vagin
2022-09-24  5:02     ` Kees Cook
2022-10-18  7:21 ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=202209212028.0C060F98@keescook \
    --to=keescook@chromium.org \
    --cc=0x7f454c46@gmail.com \
    --cc=avagin@gmail.com \
    --cc=avagin@google.com \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=fweimer@redhat.com \
    --cc=izbyshev@ispras.ru \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox