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;
pgpMmbsCYB9pQ.pgp
Description: PGP signature
