LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Yordan Karadzhov <firstname.lastname@example.org>
To: James Bottomley <James.Bottomley@HansenPartnership.com>,
Steven Rostedt <email@example.com>
Cc: firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, Linux Containers <email@example.com>,
"Eric W. Biederman" <firstname.lastname@example.org>
Subject: Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept
Date: Mon, 22 Nov 2021 17:00:25 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
On 22.11.21 г. 15:44 ч., James Bottomley wrote:
> Well, no, the information may not all exist. However, the point is we
> can add it without adding additional namespace objects.
>> Let's look the following case (oversimplified just to get the idea):
>> 1. The process X is a parent of the process Y and both are in
>> namespace 'A'.
>> 3. "unshare" is used to place process Y (and all its child processes)
>> in a new namespace B (A is a parent namespace of B).
>> 4. "setns" is s used to move process X in namespace C.
>> How would you find the parent namespace of B?
> Actually this one's quite easy: the parent of X in your setup still has
Hmm, Isn't that true only if somehow we know that (3) happened before (4).
> However, I think you're looking to set up a scenario where the
> namespace information isn't carried by live processes and that's
> certainly possible if we unshare the namespace, bind it to a mount
> point and exit the process that unshared it. If will exist as a bound
> namespace with no processes until it gets entered via the binding and
> when that happens the parent information can't be deduced from the
> process tree.
> There's another problem, that I think you don't care about but someone
> will at some point: the owning user_ns can't be deduced from the
> current tree either because it depends on the order of entry. We fixed
> unshare so that if you enter multiple namespaces, it enters the user_ns
> first so the latter is always the owning namespace, but if you enter
> the rest of the namespaces first via one unshare then unshare the
> user_ns second, that won't be true.
> Neither of the above actually matter for docker like containers because
> that's not the way the orchestration system works (it doesn't use mount
> bindings or the user_ns) but one day, hopefully, it might.
>> Again, using your arguments, I can reformulate the problem statement
>> this way: a userspace program is well instrumented
>> to create an arbitrary complex tree of namespaces. In the same time,
>> the only place where the information about the
>> created structure can be retrieved is in the userspace program
>> itself. And when we have multiple userspace programs
>> adding to the namespaces tree, the global picture gets impossible to
> So figure out what's missing in the /proc tree and propose adding it.
> The interface isn't immutable it's just that what exists today is an
> ABI and can't be altered. I think this is the last time we realised we
> needed to add missing information in/proc/<pid>/ns:
> So you can use that as the pattern.
OK, if everybody agrees that adding extra information to /proc is the right way to go, we will be happy to try
developing another PoC that implements this approach.
Thank you very much for all your help!
next prev parent reply other threads:[~2021-11-22 15:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-18 18:12 Yordan Karadzhov (VMware)
2021-11-18 18:12 ` [RFC PATCH 1/4] namespacefs: Introduce 'namespacefs' Yordan Karadzhov (VMware)
2021-11-18 18:12 ` [RFC PATCH 2/4] namespacefs: Add methods to create/remove PID namespace directories Yordan Karadzhov (VMware)
2021-11-18 18:12 ` [RFC PATCH 3/4] namespacefs: Couple namespacefs to the PID namespace Yordan Karadzhov (VMware)
2021-11-18 18:12 ` [RFC PATCH 4/4] namespacefs: Couple namespacefs to the UTS namespace Yordan Karadzhov (VMware)
2021-11-18 18:55 ` [RFC PATCH 0/4] namespacefs: Proof-of-Concept Eric W. Biederman
2021-11-18 19:02 ` Steven Rostedt
2021-11-18 19:22 ` Eric W. Biederman
2021-11-18 19:36 ` Steven Rostedt
2021-11-18 19:24 ` Steven Rostedt
2021-11-19 9:50 ` Kirill Tkhai
2021-11-19 12:45 ` James Bottomley
[not found] ` <firstname.lastname@example.org>
2021-11-19 16:42 ` James Bottomley
2021-11-19 17:14 ` Yordan Karadzhov
2021-11-19 17:22 ` Steven Rostedt
2021-11-19 23:22 ` James Bottomley
2021-11-20 0:07 ` Steven Rostedt
2021-11-20 0:14 ` James Bottomley
[not found] ` <f6ca1f5bdb3b516688f291d9685a6a59f49f1393.camel@HansenPartnership.com>
2021-11-19 16:47 ` Steven Rostedt
2021-11-19 16:49 ` Steven Rostedt
2021-11-19 23:08 ` James Bottomley
2021-11-22 13:02 ` Yordan Karadzhov
2021-11-22 13:44 ` James Bottomley
2021-11-22 15:00 ` Yordan Karadzhov [this message]
2021-11-22 15:47 ` James Bottomley
2021-11-22 16:15 ` Yordan Karadzhov
2021-11-19 14:26 ` Yordan Karadzhov
2021-11-18 21:24 ` Mike Rapoport
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [RFC PATCH 0/4] namespacefs: Proof-of-Concept' \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).