linux-kernel - Re: [PATCH v3 2/3] nsproxy: attach to namespaces via pidfds

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ftcfmxt1.fsf@x220.int.ebiederm.org>
Date:   Mon, 04 May 2020 12:09:46 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Christian Brauner <christian.brauner@...ntu.com>
Cc:     linux-kernel@...r.kernel.org,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Stéphane Graber <stgraber@...ntu.com>,
        Linux Containers <containers@...ts.linux-foundation.org>,
        Serge Hallyn <serge@...lyn.com>, Jann Horn <jannh@...gle.com>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Aleksa Sarai <cyphar@...har.com>, linux-api@...r.kernel.org
Subject: Re: [PATCH v3 2/3] nsproxy: attach to namespaces via pidfds

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.

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