On Sun, Jan 04, 2009 at 07:19:35AM +0200, lucio@proxima.alt.za wrote: > > '#p' > > allows any of my namespaces to debug processess in any other, '#s' is too > > global, and /net seems to allow any of my processes to manipulate any of my > > other processes' network connections (though I've not tested in detail to > > see what's possible.) > > So you're saying that (a) a jailed process should not have access to > the #-devices at all and (b) their equivalent /proc, /srv and /net > ought to be configured as part of the jail and should not be > modifiable. Sounds about right. I'd say that they can be modifiable if new capabilities are sendfd()'d into the namespace, but yes. > Plan 9 source often short-circuits the possibility that #-something is > not bound to the conventional place (#v comes to mind as a frequent > culprit) but that is a form of laziness that could be corrected by a > careful source audit. In which case it would be possible to treat #X > as another of those security issues that needed special treatment for > Factotum and have a kernel request that puts the #-space out of > bounds. Elsewhere in a different thread, eric grepped for explicit uses of #X paths and found very few. See <3598a04c733942f7f010ad61d83a8bc2@quanstro.net>. > Would that satisfy your requirements? Oh, sure, I haven't ever used > #| directly and I'm a bit ignorant of consequences, but the rest seems > feasible. I suspect #| being an exception wouldn't hurt, though it might be viewed as a historical wart, being the only one... could #| be made to operate more like devdup and given a canonical mountpoint? > Another aspect I noticed is that what you seem to need is a > finer-grained construction of #p and #s, but being able to construct > them one layer further down the hierarchy might suffice. "one layer further down the hierarchy" ? > Just an uneducated opinion, I've had little occasion to study those > specific devices or the others in any detail. But I am curious of > where this discussion could lead. I too. --nwf;