[9fans] directly opening Plan9 devices

[9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

Guys,

while replying to Nathaniel's post it dawned on
me that something like this:
    open("#c/cons", OWRITE|OCEXEC);
completely breaks the paradigm of namespaces.

IOW, if I wanted to construct a namespace with
a specially crafted server offering /dev/cons,
the above would easily break out of that jail.

In fact, is there *any* way at all to disallow
attaches on kernel devices? The naive method
doesn't seems to work:

 term% rfork m
 term% cat '#c/pid'
       220

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> while replying to Nathaniel's post it dawned on
> me that something like this:
>     open("#c/cons", OWRITE|OCEXEC);
> completely breaks the paradigm of namespaces.
>
> IOW, if I wanted to construct a namespace with
> a specially crafted server offering /dev/cons,
> the above would easily break out of that jail.

see RFNOMNT in rfork(2).

- erik

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 16:46 -0500, erik quanstrom wrote:
> > while replying to Nathaniel's post it dawned on
> > me that something like this:
> >     open("#c/cons", OWRITE|OCEXEC);
> > completely breaks the paradigm of namespaces.
> >
> > IOW, if I wanted to construct a namespace with
> > a specially crafted server offering /dev/cons,
> > the above would easily break out of that jail.
>
> see RFNOMNT in rfork(2).

Did you see the example I provided in the original
email? "rfork m" is *exactly* RFNOMNT. And it doesn't
seem to work for one simple reason: RFNOMNT doesn't
restrict bind(2).

So the question still stands.

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> Did you see the example I provided in the original
> email? "rfork m" is *exactly* RFNOMNT. And it doesn't
> seem to work for one simple reason: RFNOMNT doesn't
> restrict bind(2).

these are exceptions.  from port/chan.c:

	case '#':
		nomount = 1;
		up->genbuf[0] = '\0';
		n = 0;
		while(*name != '\0' && (*name != '/' || n < 2)){
			if(n >= sizeof(up->genbuf)-1)
				error(Efilename);
			up->genbuf[n++] = *name++;
		}
		up->genbuf[n] = '\0';
		/*
		 *  noattach is sandboxing.
		 *
		 *  the OK exceptions are:
		 *	|  it only gives access to pipes you create
		 *	d  this process's file descriptors
		 *	e  this process's environment
		 *  the iffy exceptions are:
		 *	c  time and pid, but also cons and consctl
		 *	p  control of your own processes (and unfortunately
		 *	   any others left unprotected)
		 */
		n = chartorune(&r, up->genbuf+1)+1;
		/* actually / is caught by parsing earlier */
>>>>		if(utfrune("M", r))
>>>>			error(Enoattach);
>>>>		if(up->pgrp->noattach && utfrune("|decp", r)==nil)
			error(Enoattach);
		t = devno(r, 1);
		if(t == -1)
			error(Ebadsharp);
		c = devtab[t]->attach(up->genbuf+n);
		break;

the first two indicated lines are redundant.
i'm not so sure about any of the exceptions.

- erik

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 17:03 -0500, erik quanstrom wrote:
> > Did you see the example I provided in the original
> > email? "rfork m" is *exactly* RFNOMNT. And it doesn't
> > seem to work for one simple reason: RFNOMNT doesn't
> > restrict bind(2).
>
> these are exceptions.  from port/chan.c:
>
> 	case '#':
> 		nomount = 1;
> 		up->genbuf[0] = '\0';
> 		n = 0;
> 		while(*name != '\0' && (*name != '/' || n < 2)){
> 			if(n >= sizeof(up->genbuf)-1)
> 				error(Efilename);
> 			up->genbuf[n++] = *name++;
> 		}
> 		up->genbuf[n] = '\0';
> 		/*
> 		 *  noattach is sandboxing.
> 		 *
> 		 *  the OK exceptions are:
> 		 *	|  it only gives access to pipes you create
> 		 *	d  this process's file descriptors
> 		 *	e  this process's environment
> 		 *  the iffy exceptions are:
> 		 *	c  time and pid, but also cons and consctl
> 		 *	p  control of your own processes (and unfortunately
> 		 *	   any others left unprotected)
> 		 */
> 		n = chartorune(&r, up->genbuf+1)+1;
> 		/* actually / is caught by parsing earlier */
> >>>>		if(utfrune("M", r))
> >>>>			error(Enoattach);
> >>>>		if(up->pgrp->noattach && utfrune("|decp", r)==nil)
> 			error(Enoattach);
> 		t = devno(r, 1);
> 		if(t == -1)
> 			error(Ebadsharp);
> 		c = devtab[t]->attach(up->genbuf+n);
> 		break;
>
> the first two indicated lines are redundant.
> i'm not so sure about any of the exceptions.

Two comments:
   0. First of all, thanks for the code snippet. I'm so used to Plan9
      having as little exceptions as possible and being very well
      documents that I sometimes forget to look for the source.
   1. This better be documented in the man pages, if you ask me.

And finally, I'd say having these exceptions is a mistake. Unless,
there's a really good reason, they break the paradigm of RFNOMNT
quite needlessly without even a hint of a benefit.

Anybody disagrees?

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[Francisco J Ballesteros]

Isn't it too restrictive, eg, not allowing you to create pipes?


On Sat, Jan 3, 2009 at 11:40 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> On Sat, 2009-01-03 at 17:03 -0500, erik quanstrom wrote:
>> > Did you see the example I provided in the original
>> > email? "rfork m" is *exactly* RFNOMNT. And it doesn't
>> > seem to work for one simple reason: RFNOMNT doesn't
>> > restrict bind(2).
>>
>> these are exceptions.  from port/chan.c:
>>
>>       case '#':
>>               nomount = 1;
>>               up->genbuf[0] = '\0';
>>               n = 0;
>>               while(*name != '\0' && (*name != '/' || n < 2)){
>>                       if(n >= sizeof(up->genbuf)-1)
>>                               error(Efilename);
>>                       up->genbuf[n++] = *name++;
>>               }
>>               up->genbuf[n] = '\0';
>>               /*
>>                *  noattach is sandboxing.
>>                *
>>                *  the OK exceptions are:
>>                *      |  it only gives access to pipes you create
>>                *      d  this process's file descriptors
>>                *      e  this process's environment
>>                *  the iffy exceptions are:
>>                *      c  time and pid, but also cons and consctl
>>                *      p  control of your own processes (and unfortunately
>>                *         any others left unprotected)
>>                */
>>               n = chartorune(&r, up->genbuf+1)+1;
>>               /* actually / is caught by parsing earlier */
>> >>>>          if(utfrune("M", r))
>> >>>>                  error(Enoattach);
>> >>>>          if(up->pgrp->noattach && utfrune("|decp", r)==nil)
>>                       error(Enoattach);
>>               t = devno(r, 1);
>>               if(t == -1)
>>                       error(Ebadsharp);
>>               c = devtab[t]->attach(up->genbuf+n);
>>               break;
>>
>> the first two indicated lines are redundant.
>> i'm not so sure about any of the exceptions.
>
> Two comments:
>   0. First of all, thanks for the code snippet. I'm so used to Plan9
>      having as little exceptions as possible and being very well
>      documents that I sometimes forget to look for the source.
>   1. This better be documented in the man pages, if you ask me.
>
> And finally, I'd say having these exceptions is a mistake. Unless,
> there's a really good reason, they break the paradigm of RFNOMNT
> quite needlessly without even a hint of a benefit.
>
> Anybody disagrees?
>
> Thanks,
> Roman.
>
>
>

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> Isn't it too restrictive, eg, not allowing you to create pipes?

pipes certianly are an exception.  why can the others
be bound for you if your jailer sees fit?

- erik

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 17:56 -0500, erik quanstrom wrote:
> > Isn't it too restrictive, eg, not allowing you to create pipes?
>
> pipes certianly are an exception.  why can the others
> be bound for you if your jailer sees fit?

Why would you call pipes an exception? Is there anything special
about them?(*)

Thanks,
Roman.

(*) There's one thing, that is somewhat related but I'm going
to ask a question about it in a different thread.

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

On Sun Jan  4 00:01:18 EST 2009, rvs@sun.com wrote:
> On Sat, 2009-01-03 at 17:56 -0500, erik quanstrom wrote:
> > > Isn't it too restrictive, eg, not allowing you to create pipes?
> >
> > pipes certianly are an exception.  why can the others
> > be bound for you if your jailer sees fit?
>
> Why would you call pipes an exception? Is there anything special
> about them?(*)

their implementation uses #| and thus requires an exception to
RFNOMNT for pipes to work for jailed processes.

i guess i don't see this one as a problem for this case.  #|
is self-contained and pipes themselves are not named.
regardless, it is inconsistent.  it might be advantagous to
replace the pipe device.  perhaps for profiling.

replacing devcons and proc seem more interseting.  by replacing
#p and #c, one could accomplish quite a bit of clustering.
i would imagine ron has done this a few times. :-)

- erik

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 23:46 +0100, Francisco J Ballesteros wrote:
> Isn't it too restrictive, eg, not allowing you to create pipes?

It depends. The point, however, is that NOT allowing to restrict
*all* attaches seem far more restrictive. ;-)

Besides, my main concern is not about restricting at all. But rather
about diverting all traffic to the filter fs. So its not pure
restriction -- more like 100% substitution. Of course, for it to
be 100% I have to have a way to disallow direct attaches to '#X'.

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> And finally, I'd say having these exceptions is a mistake. Unless,
> there's a really good reason, they break the paradigm of RFNOMNT
> quite needlessly without even a hint of a benefit.

so, it's likely that RFNOMNT was added and to avoid
breaking too many things, a few exceptions were added
with the intention of fixing and removing them.

why don't you submit a patch to rfork(2)?

- erik

Re: [9fans] directly opening Plan9 devices

[Russ Cox]

On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> And finally, I'd say having these exceptions is a mistake. Unless,
>> there's a really good reason, they break the paradigm of RFNOMNT
>> quite needlessly without even a hint of a benefit.
>
> so, it's likely that RFNOMNT was added and to avoid
> breaking too many things, a few exceptions were added
> with the intention of fixing and removing them.

i don't see why that's likely.
maybe those were simply judged to be the safe set of devices.

russ

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

>>> And finally, I'd say having these exceptions is a mistake. Unless,
>>> there's a really good reason, they break the paradigm of RFNOMNT
>>> quite needlessly without even a hint of a benefit.
>>
>> so, it's likely that RFNOMNT was added and to avoid
>> breaking too many things, a few exceptions were added
>> with the intention of fixing and removing them.
>
> i don't see why that's likely.
> maybe those were simply judged to be the safe set of devices.

for my part, i don't see why one would make it impossible to
restrict those devices.  (#| excepted, of course.)

- erik

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 15:15 -0800, Russ Cox wrote:
> On Sat, Jan 3, 2009 at 2:57 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> >> And finally, I'd say having these exceptions is a mistake. Unless,
> >> there's a really good reason, they break the paradigm of RFNOMNT
> >> quite needlessly without even a hint of a benefit.
> >
> > so, it's likely that RFNOMNT was added and to avoid
> > breaking too many things, a few exceptions were added
> > with the intention of fixing and removing them.
>
> i don't see why that's likely.
> maybe those were simply judged to be the safe set of devices.

Ok, here's a practical question: given how little use these exceptions
have in existing applications, wouldn't removing them be worth it?

Thanks,
Roman.

P.S. I can submit a patch for kernel and applications alike... ;-)

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 17:57 -0500, erik quanstrom wrote:
> > And finally, I'd say having these exceptions is a mistake. Unless,
> > there's a really good reason, they break the paradigm of RFNOMNT
> > quite needlessly without even a hint of a benefit.
>
> so, it's likely that RFNOMNT was added and to avoid
> breaking too many things, a few exceptions were added
> with the intention of fixing and removing them.
>
> why don't you submit a patch to rfork(2)?

You mean the man page, or the system call? ;-)

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[Francisco J Ballesteros]

Usign #X means doing a mount (you are attaching to the root
of the driver's tree).

However, for, drivers with letters |decp
you can always attach to them no matter if RFNOMNT was
used.

Probably it was considered too restrictive not doing so, but that's IMHO.

On Sat, Jan 3, 2009 at 10:56 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> On Sat, 2009-01-03 at 16:46 -0500, erik quanstrom wrote:
>> > while replying to Nathaniel's post it dawned on
>> > me that something like this:
>> >     open("#c/cons", OWRITE|OCEXEC);
>> > completely breaks the paradigm of namespaces.
>> >
>> > IOW, if I wanted to construct a namespace with
>> > a specially crafted server offering /dev/cons,
>> > the above would easily break out of that jail.
>>
>> see RFNOMNT in rfork(2).
>
> Did you see the example I provided in the original
> email? "rfork m" is *exactly* RFNOMNT. And it doesn't
> seem to work for one simple reason: RFNOMNT doesn't
> restrict bind(2).
>
> So the question still stands.
>
> Thanks,
> Roman.
>
>
>

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> Probably it was considered too restrictive not doing so, but that's IMHO.

there are suprisingly few uses of this.  even nsec opens /dev/bintime
directly.  none seem particularly compelling.

minooka; grep -n open `{find lib*|grep '\.[ch]$'}|grep '"#[|decp]'
libc/9sys/getpid.c:11: 	f = open("#c/pid", 0);
libc/9sys/syslog.c:83: 			sl.consfd = open("#c/cons", OWRITE|OCEXEC);
libc/9sys/sysname.c:13: 	f = open("#c/sysname", 0);

- erik

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 23:21 +0100, Francisco J Ballesteros wrote:
> Usign #X means doing a mount (you are attaching to the root
> of the driver's tree).

You're right, of course. But it feels like a very special mount
if one can refer to files served by the drivers directly through:
'#X/bla-bla'.

Thanks,
Roman.

P.S. The whole idea of letting such names be resolved feels
like a dreaded parallel namespace(s) madness from POSIX. Something
that has always tickled me the wrong way in Plan9.

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> > Usign #X means doing a mount (you are attaching to the root
> > of the driver's tree).
>
> You're right, of course. But it feels like a very special mount
> if one can refer to files served by the drivers directly through:
> '#X/bla-bla'.

s/driver/file server/
there doesn't need to be any hardware involved.

i don't understand what's special about such
a reference.  the only difference between this and
/somepath/blah-blah is that in the latter case, the
referenced element has first become part of the
namespace.  this is a lot like the difference between
a variable and an expression in c.

could you explain why you think this is special?

- erik

Re: [9fans] directly opening Plan9 devices

[lucio]

> could you explain why you think this is special?

Perhaps because it is _always_ part of the namespace, where this
discussion is specifically about restricting the namespace?  Of
course, that is how I read it, Roman will need to qualify my view.

++L

PS: I also find #X a touch special, but there is really no need to
feel that it is an intruder :-) It helps when you point out that it is
just a "macro" for something that cannot be accessed by any legitimate
name _before_ a namespace is constructed.

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> > could you explain why you think this is special?
>
> Perhaps because it is _always_ part of the namespace, where this
> discussion is specifically about restricting the namespace?  Of
> course, that is how I read it, Roman will need to qualify my view.

the anticedent special was #X/fu as opposed #X.

- erik

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sun, 2009-01-04 at 00:27 -0500, erik quanstrom wrote:
> > > Usign #X means doing a mount (you are attaching to the root
> > > of the driver's tree).
> >
> > You're right, of course. But it feels like a very special mount
> > if one can refer to files served by the drivers directly through:
> > '#X/bla-bla'.
>
> s/driver/file server/
> there doesn't need to be any hardware involved.

Well, that's part of the problem. I can't refer to things served
by the actual 9P servers via something like /srv/sources/plan9.
/srv/sources is a channel and as such it needs to be explicitly
mounted before I can access what is being served by it. If all
I could do with #X is to bind/mount it -- it would make a much
more coherent model. From my point of view, of course.

> could you explain why you think this is special?

I have nothing (major) against bind/mount interpreting names that
start with # in a special way. I feel quite confused when namec()
does that interpretation for a variety of system calls. Things
like
   term% cd '#|'
   term% pwd
   #|
just don't seem right.

But let me ask you this in return: do you feel that constraining #X to
bind/mount only would, actually, be worse compared to the behavior
we have today?

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[Roman Zhukov]

I agree with Roman. When I open #X/path I feel like back to DOS.
--
Roma

Re: [9fans] directly opening Plan9 devices

[Charles Forsyth]

>Things like
>   term% cd '#|'
>   term% pwd
>   #|
>just don't seem right.

you ask for fish; you get fish.
what's the trouble?

Re: [9fans] directly opening Plan9 devices

[Roman Shaposhnik]

On Jan 5, 2009, at 3:00 AM, Charles Forsyth wrote:
>> Things like
>>  term% cd '#|'
>>  term% pwd
>>  #|
>> just don't seem right.
>
> you ask for fish; you get fish.
> what's the trouble?

I supposed this is a matter of taste. There's as little
trouble with the above as with //foo != /foo on certain
legacy systems. Or, as was pointed out by Roman Z,
with MS-DOS drive nomenclature. They all work fine.

Yet, the closer I can get to a single namespace rooted
at / the better I feel. With #X I get at least two: one rooted
at / and the other one rooted at #.

And just to be completely clear: the #X notation doesn't
bother me when #X can be thought of as a weird cousin
of '/srv/#X'. Both are simply channels that need to be
mounted in order for the file hierarchy to appear. See,
I would go even as far as to say that, even though I know
there's no 9P involved with #X, I wouldn't mind at all
if open("#X", ORDWR) gave me an illusion of 9P messages
being exchanged.

The implicit attach that happens behind my back
when I access #X/foo is what makes me cringe.

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> And just to be completely clear: the #X notation doesn't
> bother me when #X can be thought of as a weird cousin
> of '/srv/#X'. Both are simply channels that need to be

not really.  #X references a device directly.  (hence the
attach you were complaining about.)  there is no channel.
we could argue semantics, but it's not part of the namespace
structure, so i don't think it's part of any namespace.

/srv/whatever is the opposite.  there is no direct device
reference, there is a channel and it is part of the pg's
namespace.

i think we can skip the sematic arguments and the questions
about rooting.  let's go directly to how would you unify
the big-n Namespace in a way that's clearly better?

- erik

Re: [9fans] directly opening Plan9 devices

[ron minnich]

The underlying assumption of motivation for this discussion is that
jailing (or whatever we want to call it) is somehow a good thing.
Given that every CPU we care about comes with virtualization hardware,
I just can't see the point of jails -- seems like an idea whose time
has gone, kind of like 8086 segments.

If we give up on using RFNOMNT as a jailing mechanism, do the concerns
really make any sense?

ron

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

On Wed Jan  7 11:58:04 EST 2009, rminnich@gmail.com wrote:
> The underlying assumption of motivation for this discussion is that
> jailing (or whatever we want to call it) is somehow a good thing.
> Given that every CPU we care about comes with virtualization hardware,
> I just can't see the point of jails -- seems like an idea whose time
> has gone, kind of like 8086 segments.
>
> If we give up on using RFNOMNT as a jailing mechanism, do the concerns
> really make any sense?
>
> ron

arm has virtualization?

- erik

Re: [9fans] directly opening Plan9 devices

[ron minnich]

On Wed, Jan 7, 2009 at 9:16 AM, erik quanstrom <quanstro@coraid.com> wrote:
> On Wed Jan  7 11:58:04 EST 2009, rminnich@gmail.com wrote:
>> The underlying assumption of motivation for this discussion is that
>> jailing (or whatever we want to call it) is somehow a good thing.
>> Given that every CPU we care about comes with virtualization hardware,
>> I just can't see the point of jails -- seems like an idea whose time
>> has gone, kind of like 8086 segments.
>>
>> If we give up on using RFNOMNT as a jailing mechanism, do the concerns
>> really make any sense?
>>
>> ron
>
> arm has virtualization?


Some do.

ARMs are so cheap ... don't jail things, just get another one.

ron

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> > arm has virtualization?
>
>
> Some do.
>
> ARMs are so cheap ... don't jail things, just get another one.

i wasn't aware of that.

so for my arm http/ftp server, you suggest one physical cpu
for each http/ftp connection?  how do i route the connections?

- erik

Re: [9fans] directly opening Plan9 devices

[Charles Forsyth]

>i wasn't aware of that [ARM with virtualisation].

it's a little misleading: it's just another option in the
ARM set, and fairly recent at that.  whatever it is, yours
probably hasn't got it, but it can take a little while to
work that out.

Re: [9fans] directly opening Plan9 devices

[ron minnich]

On Thu, Jan 8, 2009 at 5:37 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > arm has virtualization?
>>
>>
>> Some do.
>>
>> ARMs are so cheap ... don't jail things, just get another one.
>
> i wasn't aware of that.
>
> so for my arm http/ftp server, you suggest one physical cpu
> for each http/ftp connection?  how do i route the connections?
>

maybe you could hire one of those old Bell System operators to move
phone jacks around. Not sure on that one :-)

If you want what a jail does, I still think there are better ways on
ARM, esp. watching this conversation:
- something the equivalent of user mode linux
- or run a plan 9 kernel per http, under something like 9vx
- or something like lguest or other paravirt support

Just looking at all the mods people want for jails, these almost seem
like less work.

ron

Re: [9fans] directly opening Plan9 devices

[erik quanstrom]

> If you want what a jail does, I still think there are better ways on
> ARM, esp. watching this conversation:
> - something the equivalent of user mode linux
> - or run a plan 9 kernel per http, under something like 9vx
> - or something like lguest or other paravirt support
>
> Just looking at all the mods people want for jails, these almost seem
> like less work.

um, reductum ad absurdum?

- erik

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Thu, 2009-01-08 at 07:36 -0800, ron minnich wrote:
> If you want what a jail does, I still think there are better ways on
> ARM, esp. watching this conversation:
> - something the equivalent of user mode linux

This one sounds like a waste for a system that is so close
to supporting proper jailing in the first place.

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[Charles Forsyth]

>Just looking at all the mods people want for jails, these almost seem
>like less work.

i don't think so: i think it wouldn't be hard for simple changes
to address it. it's better than pushing the problem to a lower level
that's even less able to solve it well (or really just reintroduces the
problem at that level).

Re: [9fans] directly opening Plan9 devices

[Dave Eckhardt]

> The underlying assumption of motivation for this discussion is that
> jailing (or whatever we want to call it) is somehow a good thing.
> Given that every CPU we care about comes with virtualization
> hardware, I just can't see the point of jails -- seems like an idea
> whose time has gone, kind of like 8086 segments.

I don't see how virtualization hardware solves "the applet problem",
or least privilege in general.  While you want un-trusted or
semi-trusted code to be walled off from *most* of your stuff, you want
it to access *some* of your stuff, such as part of your screen.  If
you run it on a virtual-other machine, you still need a way to specify
which of your stuff you want exported to that other machine.  Java has
a way of doing that, which is nice and complicated.  It seems as if
considering all resources to be files and sticking different subsets
of them into different namespaces might be less painful.

This isn't an emergency for anybody running Plan 9, nor, apparently,
anybody else, since most OS's are pretty coarse-grained about
privileges, but it might be worth thinking about.

Dave Eckhardt

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Wed, 2009-01-07 at 08:55 -0800, ron minnich wrote:
> The underlying assumption of motivation for this discussion is that
> jailing (or whatever we want to call it) is somehow a good thing.
> Given that every CPU we care about comes with virtualization hardware,
> I just can't see the point of jails -- seems like an idea whose time
> has gone, kind of like 8086 segments.
>
> If we give up on using RFNOMNT as a jailing mechanism, do the concerns
> really make any sense?

Well, as was pointed out before -- not all hardware supports
virtualization. And it would be a mistake to stick a virtualization
layer into every bit of silicone.

The discussion here is really about one kernel vs. many. Hardware
not being able to run many gives you one constraint. Another
issue is that many kernels don't share anything unless explicitly
told so. A single kernel have access to everything and thus
needs to be explicitly told when access to resources is NOT to be
granted.

Just two ways to think about it. Don't know which one is better.

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Tue, 2009-01-06 at 09:17 -0500, erik quanstrom wrote:
> i think we can skip the sematic arguments and the questions
> about rooting.  let's go directly to how would you unify
> the big-n Namespace in a way that's clearly better?

At this point: I don't know. :-( The discussion was tremendously
useful for me, though. I can only hope it was also moderately
entertaining for the rest of the list.

Thanks,
Roman.

Re: [9fans] directly opening Plan9 devices

[Russ Cox]

On Sat, Jan 3, 2009 at 9:12 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> [complaint about # names]

No one has yet offered a working, cleaner idea.

Russ

Re: [9fans] directly opening Plan9 devices

[lucio]

> No one has yet offered a working, cleaner idea.

I think it is a working, perfectly clean idea, myself.  It's a
namespace of its own and there are only a very few inconsistencies
within it, well justified by the very nature of the namespace.  That
minor nits such as #s and #| being a bit off the paradigm apply
suggests that some aspects could be given more thought, but they do
not invalidate the usefulness and consistency of the design.  Rather,
they show a surprising maturity for something that probably did not
get too many iterations.

++L

Re: [9fans] directly opening Plan9 devices

[Uriel]

As I read it, rob seems to disagree with you:

> # file names were just a hack to get started - literally to get started.
They were a place holder until a better idea came along.  None has.
>
> # was never considered a great idea; I just needed some way to
name an unnamed resource.  I deliberately chose # as the character
because it's the comment character in the shell and therefore is
really irritating to use.

http://9fans.net/archive/2003/02/832

Still, clearly to this day nobody has come up with a fully
satisfactory design to replace #, and certainly not an implementation
of any such design.

Seems that despite the many years of thinking, this is still a tricky
problem, and # has turned out to be 'good enough' to keep any
alternative from appearing.

Peace

uriel

On Sun, Jan 4, 2009 at 12:41 PM,  <lucio@proxima.alt.za> wrote:
>> No one has yet offered a working, cleaner idea.
>
> I think it is a working, perfectly clean idea, myself.  It's a
> namespace of its own and there are only a very few inconsistencies
> within it, well justified by the very nature of the namespace.  That
> minor nits such as #s and #| being a bit off the paradigm apply
> suggests that some aspects could be given more thought, but they do
> not invalidate the usefulness and consistency of the design.  Rather,
> they show a surprising maturity for something that probably did not
> get too many iterations.
>
> ++L
>
>
>

Re: [9fans] directly opening Plan9 devices

[lucio]

> Seems that despite the many years of thinking, this is still a tricky
> problem, and # has turned out to be 'good enough' to keep any
> alternative from appearing.

A judgement call, no doubt.  But the list of failings doesn't seem
very long to me.  I'd say that having a /dev pre-built into the kernel
is far worse.  And inadequate.

++L

Re: [9fans] directly opening Plan9 devices

[Roman V. Shaposhnik]

On Sat, 2009-01-03 at 23:01 -0800, Russ Cox wrote:
> On Sat, Jan 3, 2009 at 9:12 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> > [complaint about # names]

Please let me know what kind of keywords or emoticons I am supposed
to include in my emails to indicate that they are *not* complaints,
but rather invitations for a discussion.

> No one has yet offered a working, cleaner idea.

Not to even suggest a 100% cleanliness, but simply
as a matter of incremental improvements here's one
simple idea.

Wouldn't the approach of treating #X as channels
instead of full fledged parallel namespace be at least
somewhat cleaner than what we have today? If the only
thing that any of the "#X" permitted was to issue a
mount/bind syscall, it would, IMHO, simplify and
clean at least the following areas:
    1.1. the need for less than ideal special case in
         namec():
            switch(name[0]){
            case '#':
         Not that we would get rid of it 100%, but it seems
         much more appropriate in bindmount()
    1.2. the need for an implicit and poorly documented
         and thus confusing ->attach in namec():
             switch(name[0]){
             case '#':
             .....
                     c = devtab[t]->attach(up->genbuf+n);
    1.3. an ability of userspace applications to bypass
         the venerable namespace mechanics

The above seems like a net gain, doesn't it?

Thanks,
Roman.