[Devel] Re: namespace and nsproxy syscalls

[Cedric Le Goater]

Serge E. Hallyn wrote:
> Quoting Herbert Poetzl (herbert at 13thfloor.at):
>>>> how to avoid having duplicate identifiers when there
>>>> is a chance that the same pid will be used again
>>>> to create a second namespace?
>>> Well at least that's simple, the pid will no longer be a valid handle to
>>> the first namespace ever since that process died  :)
>> which simply makes it inaccesible which is not
>> what you actually want, sorry ...
> 
> Nonsense.  It is still accessible via any other pids for processes in
> that namespace.  (i.e. if you're in pidns 1, and (pidns 2, pid 1)
> has started (pidns 2, pid 2) and then exited, then (pidns 2, pid 2)
> will also be known by some (pidns 1, pid X), so you can access the
> namespace via pid X from your pidns 1 process.

hmm, a few comments on the pid namespace : 

* the current model we have been talking about does not map all 
  processes of a pid namespace in the parent namespace. only the first
  process of a child namespace is required to but not its children.

* but we also said that a pid namespace can not survive the death of its
  pid 1.

> How to actually find a pid that will last long enough for you to find
> it and then access it is an exercise left to the reader  :)

well, if pid 1 is always around, it could be used as a handle but it
would be only valid if we are unsharing pid namespaces. what about
the other namespaces ? we could unshare the utsname only and still
want to reference it one way or the other. 

> In other words, I was saying that the duplicate identifiers is not a
> bug, but I thought I had left it clearly implied that the approach not
> practical, and we will need namespace ids.

yes, i'm testing such a patch as discussed on the list. I have good 
results for a full nsproxy but i'm having trouble with the mnt namespace
(used to be called namespace) which is stored in nsproxy and the 
fs_struct which is stored in the task_struct.

C.