On Tue, 2008-12-02 at 13:31 -0500, Nathaniel W Filardo wrote: > Namespaces form a large part of the security component of the Plan 9 model, > and (AFAICT) cross-namespace work is underinvestigated
It would be, in fact, a fair answer. > since it starts to look a lot like something that could compromise the > system's security. Somehow, it doesn't strike me as any more dangerous that the rest of files you have under #p/<id>/. But I'd love to be corrected. > 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. But isn't it a tad overprotective? Although, it seems that I know of at least one more thing that didn't make it into #p -- environment. #e is also only accessible to the kernel and the process itself. I have always thought that Linux got it right with /proc/self and /proc/<id>/environ. But may be, again, I'm missing some part of a bigger picture here. > 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. I *suspect* that this is, indeed, the dance Russ was referring to. Nothing wrong with dancing it. But it still leaves me curious as to why it was decided to *not* implement the support in the kernel. Thanks, Roman.
