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: <87a6i1xpis.fsf@email.froward.int.ebiederm.org>
Date:   Thu, 18 Nov 2021 12:55:07 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     "Yordan Karadzhov \(VMware\)" <y.karadz@...il.com>
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        viro@...iv.linux.org.uk, rostedt@...dmis.org, 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


Adding the containers mailing list which is for discussions like this.

"Yordan Karadzhov (VMware)" <y.karadz@...il.com> writes:

> We introduce a simple read-only virtual filesystem that provides
> direct mechanism for examining the existing hierarchy of namespaces
> on the system. For the purposes of this PoC, we tried to keep the
> implementation of the pseudo filesystem as simple as possible. Only
> two namespace types (PID and UTS) are coupled to it for the moment.
> Nevertheless, we do not expect having significant problems when
> adding all other namespace types.
>
> When fully functional, 'namespacefs' will allow the user to see all
> namespaces that are active on the system and to easily retrieve the
> specific data, managed by each namespace. For example the PIDs of
> all tasks enclosed in the individual PID namespaces. Any existing
> namespace on the system will be represented by its corresponding
> directory in namespacesfs. When a namespace is created a directory
> will be added. When a namespace is destroyed, its corresponding
> directory will be removed. The hierarchy of the directories will
> follow the hierarchy of the namespaces.

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.

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

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.

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

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

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

Since this breaks existing use cases without giving a solution.

Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>

Eric

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ