[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200504175017.ry2qhoeq3q45k2my@wittgenstein>
Date: Mon, 4 May 2020 19:50:17 +0200
From: Christian Brauner <christian.brauner@...ntu.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Jann Horn <jannh@...gle.com>, linux-api@...r.kernel.org,
Linux Containers <containers@...ts.linux-foundation.org>,
linux-kernel@...r.kernel.org,
Alexander Viro <viro@...iv.linux.org.uk>,
Michael Kerrisk <mtk.manpages@...il.com>
Subject: Re: [PATCH v3 2/3] nsproxy: attach to namespaces via pidfds
On Mon, May 04, 2020 at 12:09:46PM -0500, Eric W. Biederman wrote:
> Christian Brauner <christian.brauner@...ntu.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.
Oh, I wasn't trying to dispute that. I was just pointing at the history
where using it as a flags field in the future wasn't in principle out of
the question.
>
> 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.
Yeah, I think so. We already have a few use-cases. The syscall
interception stuff selectively attaches to subsets of namespaces
depending on what namespaces are needed to emulate a given syscall. And
the exec logic let's users select what namespaces to attach to. It's
common to setns to a subset of namespaces to perform operations with
privilege and then later attach others (often the userns).
>
> 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.
Ok, I can see that being useful. But If we do this, then a new flag
would be quite helpful. (I also think Michael had some reservations
against re-using 0 for something like this.)
But let me suggest moving your phrase from above down to here and
say that we could kick that can down the road for a follow-up extension?
Christian
Powered by blists - more mailing lists