From: lucio@proxima.alt.za
To: 9fans@9fans.net
Subject: Re: [9fans] sendfd() on native Plan 9?
Date: Sun, 4 Jan 2009 08:43:11 +0200 [thread overview]
Message-ID: <1135ea0274b24100c4dedce4e94b245f@proxima.alt.za> (raw)
In-Reply-To: <20090104061045.GJ8355@masters10.cs.jhu.edu>
> 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
next prev parent reply other threads:[~2009-01-04 6:43 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-23 18:01 Nathaniel W Filardo
2008-12-23 22:52 ` Rodolfo kix Garcia
2008-12-23 23:53 ` Francisco J Ballesteros
2008-12-24 1:10 ` Nathaniel W Filardo
2008-12-24 1:39 ` erik quanstrom
2008-12-24 3:00 ` Nathaniel W Filardo
2008-12-24 4:14 ` erik quanstrom
2008-12-24 7:36 ` Nathaniel W Filardo
2008-12-24 13:36 ` erik quanstrom
2008-12-27 20:27 ` Roman Shaposhnik
2008-12-27 20:34 ` Eric Van Hensbergen
2008-12-27 20:21 ` Roman Shaposhnik
2008-12-30 8:22 ` Nathaniel W Filardo
2008-12-30 15:04 ` Eric Van Hensbergen
2008-12-30 15:31 ` erik quanstrom
2009-01-01 22:53 ` Roman V. Shaposhnik
2009-01-01 23:57 ` Nathaniel W Filardo
2009-01-03 21:23 ` Roman V. Shaposhnik
2009-01-03 21:41 ` erik quanstrom
2009-01-03 21:59 ` Roman V. Shaposhnik
2009-01-03 23:57 ` Nathaniel W Filardo
2009-01-04 5:19 ` lucio
2009-01-04 5:48 ` erik quanstrom
2009-01-04 6:10 ` Nathaniel W Filardo
2009-01-04 6:43 ` lucio [this message]
2009-01-05 1:12 ` Roman V. Shaposhnik
2009-01-05 1:32 ` erik quanstrom
2009-01-05 3:48 ` lucio
2009-01-04 17:32 ` erik quanstrom
2009-01-04 18:23 ` lucio
2009-01-05 1:24 ` Roman V. Shaposhnik
2009-01-04 5:58 ` Nathaniel W Filardo
2009-01-04 6:26 ` lucio
2009-01-04 15:46 ` erik quanstrom
2009-01-05 4:30 ` Roman V. Shaposhnik
2008-12-24 1:17 ` Nathaniel W Filardo
2008-12-27 17:06 ` Russ Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1135ea0274b24100c4dedce4e94b245f@proxima.alt.za \
--to=lucio@proxima.alt.za \
--cc=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).