public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Christian Brauner <christian.brauner@ubuntu.com>
Cc: linux-kernel@vger.kernel.org,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Stéphane Graber" <stgraber@ubuntu.com>,
	"Linux Containers" <containers@lists.linux-foundation.org>,
	"Serge Hallyn" <serge@hallyn.com>, "Jann Horn" <jannh@google.com>,
	"Michael Kerrisk" <mtk.manpages@gmail.com>,
	"Aleksa Sarai" <cyphar@cyphar.com>,
	linux-api@vger.kernel.org
Subject: Re: [PATCH v3 2/3] nsproxy: attach to namespaces via pidfds
Date: Mon, 04 May 2020 12:09:46 -0500	[thread overview]
Message-ID: <87ftcfmxt1.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20200504163907.jjgqe7qnnjpw4uwo@wittgenstein> (Christian Brauner's message of "Mon, 4 May 2020 18:39:07 +0200")

Christian Brauner <christian.brauner@ubuntu.com> writes:

> On Mon, May 04, 2020 at 11:25:07AM -0500, Eric W. Biederman wrote:
>> 
>> I am not thrilled about treating nstype as a flags fields when it is not
>> currently.  It was my hope when I designed the interface that not
>> treating nstype as a flags field would save us from the problem of bits
>> running out.
>
> Hm, I researched the setns() syscall history before that and I didn't
> see that reasoning anywhere. The "nstype" arg was originally advertised
> on the list as "having a flags field is useful in general".

Take a look at the code.  At the end of the day nstype is not treated at
all like a flags field.

It isn't a very important point.  And it was certainly easier to use
the existing bits for essentially their existing meanings.  But it was
certainly something I was thinking at the time.

I think I left it as we can see either way, depending on how things
evolve.

I can imagine a use for a nstype being a single namespace from a pidfd.
Do you have any actual usecases for setting some but not all of the
namespaces from a pidfd?  If we don't have a compelling reason
I would like to kick that can down the road a ways farther.

I am also remembering that that setns freed the low 8 bits.  Which gave
some freedom beyond clone.

>> That aside.  It would be very good if the default version of setting
>> everything from a pidfd would set the root directory from the process it
>> is copying everything else from.
>
> I'm not sure I follow completely. If you specify CLONE_NEWNS then we do
> set the root directory with set_fs_root() in commit_nsset(). Or are you
> saying we should always do that independent of whether or not
> CLONE_NEWNS is specified? And if so could you explain why we'd want
> that? I'm sure I'm missing something!

I am suggesting that when we do:

"setns(pidfd, 0)" or "setns(pidfd, SETNS_PIDFD)"

That the result is not just the namespaces changing but also the root
directory changing to the pids root directory.  Something where the
whole is greater than the parts.

Eric


  reply	other threads:[~2020-05-04 17:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-04 14:41 [PATCH v3 0/3] nsproxy: attach to multiple namespaces Christian Brauner
2020-05-04 14:41 ` [PATCH v3 1/3] nsproxy: add struct nsset Christian Brauner
2020-05-04 16:15   ` Eric W. Biederman
2020-05-04 16:25     ` Christian Brauner
2020-05-04 14:41 ` [PATCH v3 2/3] nsproxy: attach to namespaces via pidfds Christian Brauner
2020-05-04 16:25   ` Eric W. Biederman
2020-05-04 16:39     ` Christian Brauner
2020-05-04 17:09       ` Eric W. Biederman [this message]
2020-05-04 17:50         ` Christian Brauner
2020-05-04 14:41 ` [PATCH v3 3/3] selftests/pidfd: add pidfd setns tests Christian Brauner

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=87ftcfmxt1.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=christian.brauner@ubuntu.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=cyphar@cyphar.com \
    --cc=jannh@google.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=serge@hallyn.com \
    --cc=stgraber@ubuntu.com \
    --cc=viro@zeniv.linux.org.uk \
    /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