[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <48d53b265664f020579c70a7bffc45156032bf69.camel@HansenPartnership.com>
Date: Fri, 19 Nov 2021 19:14:22 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Yordan Karadzhov <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>,
"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept
On Fri, 2021-11-19 at 19:07 -0500, Steven Rostedt wrote:
> On Fri, 19 Nov 2021 18:22:55 -0500
> James Bottomley <James.Bottomley@...senPartnership.com> wrote:
>
> > But I could write a script or a tool to gather all the information
> > without this filesystem. The namespace tree can be reconstructed
> > by anything that can view the process tree and the /proc/<pid>/ns
> > directory.
>
> So basically you're stating that we could build the same thing that
> the namespacefs would give us from inside a privileged container that
> had access to the system procfs?
I think so, yes ... and if some information is missing, we could export
it for you. This way the kernel doesn't prescribe what the namespace
tree looks like and the tool can display it in many different ways.
For instance, your current RFC patch misses the subtlety of the owning
user namespace, but that could simply be an alternative view presented
by a userspace tool.
James
Powered by blists - more mailing lists