On Mon, 2021-11-22 at 17:00 +0200, Yordan Karadzhov wrote: > > 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 it. > > Hmm, Isn't that true only if somehow we know that (3) happened before > (4). This depends. There are only two parented namespaces: pid and user. You said you were only interested in pid for now. setns on the process only affects pid_for_children because you have to fork to enter the pid namespace, so in your scenario X has a new ns/pid_for_children but its own ns/pid never changed. It's the ns/pid not the ns/pid_for_children which is the parent. This makes me suspect that the specific thing you're trying to do: trace the pid parentage, can actually be done with the information we have now. If you do this with the user_ns, then you have a problem because it's not fork on entry. But, as I listed in the examples, there are a load of other problems with tracing the user_ns tree. James
