On Tue, Dec 02, 2008 at 10:04:57AM -0800, Roman V. Shaposhnik wrote:
> I would imagine that making '#p'/<proc id>/ns writable and receptive
> to messages of exact same format that is being output right now
> (plus an 'unmount X Y' message)  would be a very natural thought in
> a Plan9 environment. Yet, it wasn't implemented that way which makes 
> me believe that I do (as usual) overlook something obvious here. 
> Please give me a hint to what it might be that renders the idea as a bad
> one.

Namespaces form a large part of the security component of the Plan 9 model,
and (AFAICT) cross-namespace work is underinvestigated since it starts to
look a lot like something that could compromise the system's security.  At
the moment, we can make claims like "once fork(NEWNS) succeeds, I and the
kernel are the only agents that are able to manipulate my namespace."  This
is a nice statement to be able to make.

Since /proc/$PID/ns is "mostly" an rc script, it's possible (sometimes) to
"see into" another proc's namespace by following along... given that, what
would be wrong with your /set server exporting a ns-like file that simply
detailed its own manipulations to its namespace?  You'd have to assume that
/net (or /srv, if you prefer) was shared between /set and you, I suppose...
which is probably OK.

> Thanks,
> Roman.
> 
> P.S. Thinking for a couple more minutes makes me believe that a 
> writable '#p'/<proc id>/ns might even be used to implement 
> mount/bind syscall. Which, on the surface, would make it even
> more appealing.

Intriguing.  I guess it wasn't done this way so that processes could be
constructed without /proc mounted... (though you could always manipulate
'#p/$PID/ns'... that might be considered a bug, tho')

--nwf;