All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.