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

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

Date:   Fri, 19 Nov 2021 18:08:08 -0500
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Steven Rostedt <rostedt@...dmis.org>
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, akpm@...ux-foundation.org, vvs@...tuozzo.com,
        shakeelb@...gle.com, christian.brauner@...ntu.com,
        mkoutny@...e.com, Linux Containers <containers@...ts.linux.dev>,
        Steven Rostedt <rostedt@...dmis.org>,
        "Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept

[trying to reconstruct cc list, since the cc: field is bust again]
> On Fri, 19 Nov 2021 11:47:36 -0500
> Steven Rostedt <rostedt@...dmis.org> wrote:
> 
> > > Can we back up and ask what problem you're trying to solve before
> > > we start introducing new objects like namespace name?
> 
> TL;DR; verison:
> 
> We want to be able to install a container on a machine that will let
> us view all namespaces currently defined on that machine and which
> tasks are associated with them.
> 
> That's basically it.

So you mentioned kubernetes.  Have you tried

kubectl get pods --all-namespaces

?

The point is that orchestration systems usually have interfaces to get
this information, even if the kernel doesn't.  In fact, userspace is
almost certainly the best place to construct this from.

To look at this another way, what if you were simply proposing the
exact same thing but for the process tree.  The push back would be that
we can get that all in userspace and there's even a nice tool (pstree)
to do it which simply walks the /proc interface.  Why, then, do we have
to do nstree in the kernel when we can get all the information in
exactly the same way (walking the process tree)?

James