From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1135ea0274b24100c4dedce4e94b245f@proxima.alt.za>
To: 9fans@9fans.net
Date: Sun,  4 Jan 2009 08:43:11 +0200
From: lucio@proxima.alt.za
In-Reply-To: <20090104061045.GJ8355@masters10.cs.jhu.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] sendfd() on native Plan 9?
Topicbox-Message-UUID: 77e23548-ead4-11e9-9d60-3106f5b1d025

> RFNOMNT has been brought up repeatedly and, while it's certainly better than
> nothing, it is too harsh!  It simultaneously:
>   -> restricts access to kernel devices via # paths
>   -> prevents any and all additional mount requests.
>
Well, it does only the latter, the first is just a special case.  If
you see these as different, I think you may have a slightly distorted
picture and although it is accurate at this point, it may prove
erroneous later.

> 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, if I understand all this rather heady stuff
correctly, is largely your sendfd(): I want access to some external
namespace by posting its handle (a text string) to the superserver
(echo mount 'hisnamespace' > /dev/superserver/ctl) 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.

Again, I'd love to be corrected if the above scenario is based on a
misunderstanding.

> 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?

Something tells me that there may have to be a different solution,
because as Erkik correctly points out, it is not the #-name that makes
a difference, that is just a convenient notation.  For your proposal
to make sense, it must address the properties of the #-space that make
it special/different from the rest of the namespace, specifically from
the point of view of creating a secure namespace jail.  It is that
property that needs to be leveraged by an RFCJAIL option, feeling
secure that it will not include #| when applied.

++L