* [9fans] removing a name from the name space
@ 1998-11-20 7:05 Richard
0 siblings, 0 replies; 8+ messages in thread
From: Richard @ 1998-11-20 7:05 UTC (permalink / raw)
Thanks to Steve Kilbane and "presotto" for answering my question.
--
to mail me, replace "roo" with "ru".
^ permalink raw reply [flat|nested] 8+ messages in thread
* [9fans] removing a name from the name space
@ 1998-11-20 7:15 Nigel
0 siblings, 0 replies; 8+ messages in thread
From: Nigel @ 1998-11-20 7:15 UTC (permalink / raw)
Brilliant! That really brightened up my day working with an inferior OS.
-----Original Message-----
From: dmr@plan9.bell-labs.com [mailto:dmr@plan9.bell-labs.com]
Sent: Friday, November 20, 1998 4:13 AM
To: 9fans@cse.psu.edu
Subject: Re: [9fans] removing a name from the name space
> does this guarantee that if you cd to sandbox/x/bin/..
> you will be in sandbox/x, not /386?
> i found the semantics of ".." always seemed rather unobvious within
> the plan 9 namespace (particularly with union directories...)
> is there a simple way of understanding it?
The Black Knight says, "It's just a flesh wound!"
- D.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [9fans] removing a name from the name space
@ 1998-11-20 4:12 dmr
0 siblings, 0 replies; 8+ messages in thread
From: dmr @ 1998-11-20 4:12 UTC (permalink / raw)
> does this guarantee that if you cd to sandbox/x/bin/..
> you will be in sandbox/x, not /386?
> i found the semantics of ".." always seemed rather unobvious within
> the plan 9 namespace (particularly with union directories...)
> is there a simple way of understanding it?
The Black Knight says, "It's just a flesh wound!"
- D.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [9fans] removing a name from the name space
@ 1998-11-19 20:49 forsyth
0 siblings, 0 replies; 8+ messages in thread
From: forsyth @ 1998-11-19 20:49 UTC (permalink / raw)
>>is there a simple way of understanding it?
i believe .. simply picks one of the parents.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [9fans] removing a name from the name space
@ 1998-11-19 15:53 Roger
0 siblings, 0 replies; 8+ messages in thread
From: Roger @ 1998-11-19 15:53 UTC (permalink / raw)
> # create a sandbox
> mkdir sandbox/x
> mkdir sandbox/x/bin
> mkdir sandbox/dev
> > sandbox/dev/cons
> > sandbox/dev/mouse
> > sandbox/dev/time
> mkdir sandbox/tmp
>
> # bind things into it
> bind -c /386/safebin sandbox/x/bin
> bind -c /dev/cons sandbox/x/dev/cons
> bind -c /dev/mouse sandbox/x/dev/mouse
> bind -c /dev/time sandbox/x/dev/time
>
> # replace the root
> bind -c sandbox/x /
> magic call to turn off '#' access
>
> At this point you can exec a game and it will be hard
> pressed to get to things outside the original namespace
> though it can still change its namespace.
does this guarantee that if you cd to sandbox/x/bin/..
you will be in sandbox/x, not /386?
i found the semantics of ".." always seemed rather unobvious within
the plan 9 namespace (particularly with union directories...)
is there a simple way of understanding it?
cheers,
rog.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [9fans] removing a name from the name space
@ 1998-11-19 15:22 presotto
0 siblings, 0 replies; 8+ messages in thread
From: presotto @ 1998-11-19 15:22 UTC (permalink / raw)
You might want to do something that we did in inferno also.
We added a system call that disables a process' ability to
dereference '#xxxx' names, i.e., local devices. That way,
once you've built a namespace, you can keep anyone from
adding things to it that you don't already have access to.
That gives you a more secure sandbox to play in.
To build a safe namespace, you really wan't one where you
can't expose files via unbinding. For example, hiding
/x/y/x
by binding an empty directory onto /x/y isn't very safe since
the program can unbind it. You would be best served by
buidling a namespace starting at the root and working
your way down. For example:
# create a sandbox
mkdir sandbox/x
mkdir sandbox/x/bin
mkdir sandbox/dev
> sandbox/dev/cons
> sandbox/dev/mouse
> sandbox/dev/time
mkdir sandbox/tmp
# bind things into it
bind -c /386/safebin sandbox/x/bin
bind -c /dev/cons sandbox/x/dev/cons
bind -c /dev/mouse sandbox/x/dev/mouse
bind -c /dev/time sandbox/x/dev/time
# replace the root
bind -c sandbox/x /
magic call to turn off '#' access
At this point you can exec a game and it will be hard
pressed to get to things outside the original namespace
though it can still change its namespace.
------ forwarded message follows ------
>From cse.psu.edu!owner-9fans Thu Nov 19 04:19:52 EST 1998
Received: from plan9.bell-labs.com ([135.104.9.2]) by plan9; Thu Nov 19 04:19:52 EST 1998
Received: from cse.psu.edu ([130.203.3.50]) by plan9; Thu Nov 19 04:19:51 EST 1998
Received: from localhost (majordom@localhost)
by cse.psu.edu (8.8.8/8.8.8) with SMTP id EAA15022;
Thu, 19 Nov 1998 04:19:36 -0500 (EST)
Received: by claven.cse.psu.edu (bulk_mailer v1.5); Thu, 19 Nov 1998 04:18:39 -0500
Received: (from majordom@localhost)
by cse.psu.edu (8.8.8/8.8.8) id EAA14977
for 9fans-outgoing; Thu, 19 Nov 1998 04:18:34 -0500 (EST)
X-Authentication-Warning: claven.cse.psu.edu: majordom set sender to owner-9fans using -f
Received: from ohio.river.org (river.org [209.24.233.15])
by cse.psu.edu (8.8.8/8.8.8) with ESMTP id EAA14973
for <9fans@cse.psu.edu>; Thu, 19 Nov 1998 04:18:30 -0500 (EST)
Received: (from ru@localhost) by ohio.river.org (8.8.8/8.7.3) id BAA13296; Thu, 19 Nov 1998 01:18:25 -0800 (PST)
Date: Thu, 19 Nov 1998 01:18:25 -0800 (PST)
Message-Id: <199811190918.BAA13296@ohio.river.org>
From: Richard Uhtenwoldt <roo@river.org>
To: 9fans@cse.psu.edu
Subject: [9fans] removing a name from the name space
Sender: owner-9fans@cse.psu.edu
Reply-To: 9fans@cse.psu.edu
Precedence: bulk
using BIND, a process can
customize a namespace so that /big/long/file/name
can be referred to as /biggie.
is there a way to *remove* /big/long/file/name
from the namespace as seen from a particular process?
why would one want to do that? well, suppose that I
want to run a game that does not need the network.
before I run the game, I remove the file that "exports"
(terminology?) the network interface from the game's
namespace so that it impossible for the game to act as a
trojan horse. so, it is useful for security reasons.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [9fans] removing a name from the name space
@ 1998-11-19 12:13 steve_kilbane
0 siblings, 0 replies; 8+ messages in thread
From: steve_kilbane @ 1998-11-19 12:13 UTC (permalink / raw)
On 19/11/98 09:18:25 Richard Uhtenwoldt wrote:
> why would one want to do that? well, suppose that I
> want to run a game that does not need the network.
> before I run the game, I remove the file that "exports"
> (terminology?) the network interface from the game's
> namespace so that it impossible for the game to act as a
> trojan horse. so, it is useful for security reasons.
Wrong way round. You create a new namespace, using rfork(), and only attach
to it the parts of the system that you need. See the ftp and http servers
for examples.
steve
^ permalink raw reply [flat|nested] 8+ messages in thread
* [9fans] removing a name from the name space
@ 1998-11-19 9:18 Richard
0 siblings, 0 replies; 8+ messages in thread
From: Richard @ 1998-11-19 9:18 UTC (permalink / raw)
using BIND, a process can
customize a namespace so that /big/long/file/name
can be referred to as /biggie.
is there a way to *remove* /big/long/file/name
from the namespace as seen from a particular process?
why would one want to do that? well, suppose that I
want to run a game that does not need the network.
before I run the game, I remove the file that "exports"
(terminology?) the network interface from the game's
namespace so that it impossible for the game to act as a
trojan horse. so, it is useful for security reasons.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~1998-11-20 7:15 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-11-20 7:05 [9fans] removing a name from the name space Richard
-- strict thread matches above, loose matches on Subject: below --
1998-11-20 7:15 Nigel
1998-11-20 4:12 dmr
1998-11-19 20:49 forsyth
1998-11-19 15:53 Roger
1998-11-19 15:22 presotto
1998-11-19 12:13 steve_kilbane
1998-11-19 9:18 Richard
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).