On Sun, 2009-01-04 at 08:43 +0200, lu...@proxima.alt.za wrote: > > Constructing a namespace without RFNOMNT that does not have #s (say) bound > > is not really securing #s (and its other consumers) against that namespace's > > actions. Constructing a namespace with RFNOMNT and without #s bound does > > at least two bad things: > > -> it makes it impossible to pass fds around between processes in this > > namespace, as there is now no /srv backing. > > -> it prohibits import of additional resources. > > > You could have a superserver process that constructs additional > namespace entries as mkdir()s within its own directory hierarchy, > could you not?
That was the solution I was trying to hint at in my original email. I still haven't seen Nathaniel's reply to that. > and suddenly find > /dev/superserver/999/hisnamespace for me to mess to my heart's > content. Like you, I'd then find it annoying that RFNOMNT stops me > from abbreviating this as /n/hisnamespace for practical purposes. RFNOMNT does NOT restrict bind(2). Thus you can always do that even in a fully jailed process. > > The claim is that it might be useful to have namespaces where the mount > > table remained open to additional mounts (etc.) but for which the magic > > shortcut and proxy circumvention mechanism of #X was not available. > > In other words, restrict RFNOMNT (obviously by a totally different > name and possibly mechanism) to the #X exception instead of its > current function. Non? My personal opinion (which seems to be shared by Erik) is that it is a slippery slope that can be avoided. I haven't seen the arguments to the contrary so far. Thanks, Roman.
