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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20200504163907.jjgqe7qnnjpw4uwo@wittgenstein>
Date:   Mon, 4 May 2020 18:39:07 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     "Eric W. Biederman" <ebiederm@...ssion.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

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".

> 
> 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!

Christian