Re: [9fans] A note about new software for Plan 9

[mycroftiv@sphericalharmony.com]

Bakul Shah wrote:
> Some motivating examples may help.  Perhaps you can show
> 1. Initial state of the world (show with the help of a few ls)
> 2. A sequence of commands to change it
> 3. What the world looks like finally

I have actually documented these things in this manner in the ANTS
paper that can be found at http://ants.9gridchan.org/doc/ants.ps and
it also overlaps with the tutorial material presented at
http//antfarm.9gridchan.org/tutorial and the related pages.

Do you think it would be helpful or welcome to re-post some of this
material here on 9fans?  I have tried to document all of these things
extensively as part of my work.

> And a brief description why this would be desirable.  And how
> it compares with just using chroot. Most people here can
> perhaps read rc code more readily than elaborate explanations!

Part of the comparison is that "chroot" does not exist in Plan 9, so
"rerootwin" is very similar to chroot in a conceptual sense.  The
desirability is simply that if you have multiple independent
namespaces, you need a mechanism to move freely between them.  The
"rerootwin" script and namespace file is really very simple.  After
checking and preparing the namespace, rerootwin does:

oldterm=oldterm.$pid
oldwsys=oldwsys.$pid
srvfs -p 0600 oldterm.$pid /mnt/term
srvfs -p 0600 oldwsys.$pid /mnt/wsys

And then does auth/newns into a custom parameterized namespace file
which has binds like this:

mount -c /srv/$oldterm $pivot/$oldterm
mount -c /srv/$oldwsys $pivot/$oldwsys
bind $pivot/$oldterm/dev/cons /dev/cons
bind $pivot/$oldterm/dev/consctl /dev/consctl

The reason you can't just use auth/newns and the standard namespace
file is that if you do this when you are connected via cpu or
drawterm, the standard namespace file will not re-bind the window
system and so you won't be able to run gui programs in the new
namespace.  Rerootwin "passes the devices through" via srvfs so you
can reroot to a new namespace but still start new GUI applications.

> In *BSD a jail is more than chroot since it can also get access
> to its own interfaces, networking stack, init process, devices
> etc. And it can't look at the state of another jail or the
> host. And another host on the net doesn't even know it is
> talking to a jail.

Yes I absolutely understand this and I have tried to be careful to
emphasize that I am using "jails" as a way of understanding what I am
talking about.  What I am doing is not intended as full isolation, and
is not intended for security - I actually write about this in the faq
on the antfarm site.  Talking about jails/vms is just the only way I
know to express the idea of an independent group of processes which
act to create a user-environment.

In fact, the ANTS design is deliberately pursuing integration between
these seperate namespaces rather than isolation.  My goal is not to
"isolate" each environment - it is to create environments which are
independent, but share data freely and deliberately make use of
resources from the other environments.

So even though the core idea - "independent userspaces" - is similar,
the implementation and purpose is very different.  I am trying to make
the independent namespaces so that each namespace can serve a
different function or role within the network - not impose security
and isolation on users.  The most important separate namespace is the
kernel-device only namespace, which acts as an admin/launching layer
for the other user namespaces.

> To do something similar you will have to constrain each jail
> to see a subset of processes, give it its own /dev, /env etc.
> Not sure how you do this.

As explained above (just to be clear) I am deliberately not doing
this, because it is not the intended purpose.  It would be possible to
adapt the ideas of ANTS into a more jail like framework by using a lot
of RFNOMNT to isolate things and take other steps, but that isn't how
I use these tools.  I want independent namespaces so I can administer
my fossil and my venti "from beneath" so that if the fossil or venti
need to be stopped, I still have all my needed tools available.  I
want independent namespaces so I can have 9front and Bell labs at the
same time and actually share namespace between the two as needed.

In fact one of the major ideas in ANTS is using a 9p fs called "hubfs"
to deliberately create persistent data connections between these
independent namespaces.  In the setup I use, each of my independent
namespaces has access to persistent shells in every other namespace
and every other machine - so the architecture is literally the exact
opposite of "security and isolation" it is fluid data sharing between
independent userspaces.

I hope these answers have been relevant and that my tone is friendly
and informative.  :) Your questions are very appropriate and
insightful, and I have made an attempt to extensively answer them in
the documentation I have created.  I have a full length paper, full
standard Plan 9 manpages, additional textual documentation within the
ants software folder, and five step-by-step tutorials done with
pre-installed VMs which attempt to comprehensively explain how to use
ANTS, how it is built, and what its purposes are.

I really appreciate the interest!  I hope I am responding and
explaining in a clear way

Ben Kidwell
"mycroftiv"