From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sun, 4 Jan 2009 17:12:34 -0800 From: "Roman V. Shaposhnik" In-reply-to: <1135ea0274b24100c4dedce4e94b245f@proxima.alt.za> To: lucio@proxima.alt.za, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-id: <1231117954.11463.309.camel@goose.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT References: <1135ea0274b24100c4dedce4e94b245f@proxima.alt.za> Subject: Re: [9fans] sendfd() on native Plan 9? Topicbox-Message-UUID: 7937dde4-ead4-11e9-9d60-3106f5b1d025 On Sun, 2009-01-04 at 08:43 +0200, lucio@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.