linux-kernel - Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept

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: <20211118142440.31da20b3@gandalf.local.home>
Date:   Thu, 18 Nov 2021 14:24:40 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     ebiederm@...ssion.com (Eric W. Biederman)
Cc:     "Yordan Karadzhov \(VMware\)" <y.karadz@...il.com>,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        viro@...iv.linux.org.uk, mingo@...hat.com, hagen@...u.net,
        rppt@...nel.org, James.Bottomley@...senPartnership.com,
        akpm@...ux-foundation.org, vvs@...tuozzo.com, shakeelb@...gle.com,
        christian.brauner@...ntu.com, mkoutny@...e.com,
        Linux Containers <containers@...ts.linux.dev>
Subject: Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept

On Thu, 18 Nov 2021 12:55:07 -0600
ebiederm@...ssion.com (Eric W. Biederman) wrote:

> It is not correct to use inode numbers as the actual names for
> namespaces.
> 
> I can not see anything else you can possibly uses as names for
> namespaces.

This is why we used inode numbers.

> 
> To allow container migration between machines and similar things
> the you wind up needing a namespace for your names of namespaces.

Is this why you say inode numbers are incorrect?

There's no reason to make this into its own namespace. Ideally, this file
system should only be for privilege containers. As the entire point of this
file system is to monitor the other containers on the system. In other
words, this file system is not to be used like procfs, but instead a global
information of the containers running on the host.

At first, we were not going to let this file system be part of any
namespace but the host itself, but because we want to wrap up tooling into
a container that we can install on other machines as a way to monitor the
containers on each machine, we had to open that up.

> 
> Further you talk about hierarchy and you have not added support for the
> user namespace.  Without the user namespace there is not hierarchy with
> any namespace but the pid namespace. There is definitely no meaningful
> hierarchy without the user namespace.

Great, help us implement this.

> 
> As far as I can tell merging this will break CRIU and container
> migration in general (as the namespace of namespaces problem is not
> solved).

This is not to be a file system that is to be migrated. As the point of
this file system is to monitor the other containers, so it does not make
sense to migrate it.

> 
> Since you are not solving the problem of a namespace for namespaces,
> yet implementing something that requires it.

Why is it needed?

> 
> Since you are implementing hierarchy and ignoring the user namespace
> which gives structure and hierarchy to the namespaces.

We are not ignoring it, we are RFC'ing for advice on how to implement it.

> 
> Since this breaks existing use cases without giving a solution.

You don't understand proof-of-concepts and RFCs do you?

-- Steve