[9fans] 9vx/vx32 - Out of ignorance

[9fans] 9vx/vx32 - Out of ignorance

[Lucio De Re]

Besides the issue of (not) understanding TAP and so having no access to
networking, what struck me while experimenting with a very remarkable 9vx
installation (9vx is impressive, not my installation thereof :-) was that
if you start it as root, you retain root credentials within the sandbox,
irrespective of user selection at start up of 9vx.  Given that 9vx seems
pretty comfortable as an arbitrary user, would it make sense for me to
find a location where a switch to the specified user can take place?

Admittedly, that does not correspond to the Plan 9 model where Eve has
unrestricted access to devices, but in a hosted environment that can be
excused (and documented).  My thinking is that 9vx could start up as root
to install the TAP device (nothing else so far has alerted me to a need
for root permissions), then switch user to the selected one (if it exists,
"nobody" may be needed if there is no equivalent in the host repertoire)
once setting up is complete.

Back to the question, then: is there any reason why I should not be
looking into doing this?

Another thought that struck me, in passing, is whether the TAP device
should be set up in vx32 rather than in 9vx.  I am not familiar with
the boundary between these, so the question may seem silly to others,
to me the logic seems a bit strained right now.

And if anybody can arrange a short lesson on using networking under 9vx,
that would also be greatly appreciated.

++L

Re: [9fans] 9vx/vx32 - Out of ignorance

[ron minnich]

On Sun, Sep 12, 2010 at 9:17 AM, Lucio De Re <lucio@proxima.alt.za> wrote:

> Back to the question, then: is there any reason why I should not be
> looking into doing this?

I'm kind of a "go ahead and do it" person w.r.t. this, and I certainly
have no ownership of 9vx, so I'd say "why not?" The more the merrier.

orn

Re: [9fans] 9vx/vx32 - Out of ignorance

[yy]

2010/9/12 Lucio De Re <lucio@proxima.alt.za>:
> My thinking is that 9vx could start up as root
> to install the TAP device (nothing else so far has alerted me to a need
> for root permissions), then switch user to the selected one (if it exists,
> "nobody" may be needed if there is no equivalent in the host repertoire)
> once setting up is complete.

The advantage of the tap device is precisely that it does not need
root permissions. You need those permissions to manage the devices,
but that will be normally done by tunctl or openvpn. Those are the
programs that have to worry about being run as root, not 9vx. In other
words: you need to be root to create the tap device, but not to use
it.

> And if anybody can arrange a short lesson on using networking under 9vx,
> that would also be greatly appreciated.

Inside 9vx, networking with tap devices is not different to using
physical devices. At the host system level, it works as it does in
qemu (there could be more bugs though). There are many qemu tutorials
with sample scripts and better explanations than what I could give.
The particular configuration I'm using is documented at:

http://wiki.archlinux.org/index.php/QEMU#Tap_Networking_with_QEMU

Based on the qemu-ifup/down scripts described there I wrote a 9vx-tap
script you can find at:

http://bitbucket.org/yiyus/vx32/src/tip/src/9vx/9vx-tap

Probably disecting that script is the best way to understand how the
bridge, the tap devices and 9vx play together.

--
- yiyus || JGL . 4l77.com

Re: [9fans] 9vx/vx32 - Out of ignorance

[Bakul Shah]

On Sun, 12 Sep 2010 19:30:05 +0200 yy <yiyu.jgl@gmail.com>  wrote:
> 2010/9/12 Lucio De Re <lucio@proxima.alt.za>:
> > My thinking is that 9vx could start up as root
> > to install the TAP device (nothing else so far has alerted me to a need
> > for root permissions), then switch user to the selected one (if it exists,
> > "nobody" may be needed if there is no equivalent in the host repertoire)
> > once setting up is complete.
>
> The advantage of the tap device is precisely that it does not need
> root permissions. You need those permissions to manage the devices,
> but that will be normally done by tunctl or openvpn. Those are the
> programs that have to worry about being run as root, not 9vx. In other
> words: you need to be root to create the tap device, but not to use
> it.

On a mac you don't need root perms to open a tap device.
(using Mattias Nissler's tuntap package). On FreeBSD you can
set sysctl
    net.link.tap.user_open=1
to allow a nonroot process to open a tap device.  On linux
you have tunctl.

But I agree you don't need 9vx to plan root games. You can
wrap a script around it.

> > And if anybody can arrange a short lesson on using networking under 9vx,
> > that would also be greatly appreciated.

You have a number of choices.

- If you only want to initiate connects from within 9vx to
  the outside world 9vx's original choice is good enough.
- If you want to provide one or more services in 9vx that
  others can connect to, you can perhaps just setup port
  forwarding (like in ssh). The idea is to open a listening
  socket on host when a 9vx process opens a listening port.
- If you want to fire up multiple 9vx instances, set up nfs
  or some such services the host may also provide, provide
  multiple network interfaces, or play with networking within
  9vx, then you need a "full fledged host" that does its
  own network processing.

  Here you have two choices:

  - open a host interface in "promiscuous" mode and filter
    packets based on dest mac address (which is sort of like
    bridging).

  - use a tap device.  Basically 9vx has to open host's
    /dev/tapN. This should map to an ether interface within
    9vx.  Packets sent from 9vx appear as *input packets* on
    the host network interface tapN.  Packets output to (or
    relayed to) host netif tapN appear as input data on
    /dev/tapN.  To send/recv packets to/from a real network
    you have three choices (to be done on the host side):

    - bridge to a phys device
    - route (the host will forward. If you need dhcp in 9vx the
      host must provide or relay dhcp)
    - NAT (the host will do address translation)

    Each has its pros and cons. Bridging, if it can be made
    to work, is the simplest. But AFAIK you can't do bridging
    on a host connected only via a wireless connection (at
    least I don't know how to do that). MacOS ifconfig man
    page, which seems to be cribbed from FreeBSD, talks about
    bridging related subcommands and if_bridge(4) but to my
    knowledge there is no built in bridging support in it.
    But vmware and VirtualBox seems to allow bridging so
    there must be a way....

    *BSD and linux provide bridging.

Re: [9fans] 9vx/vx32 - Out of ignorance

[Lucio De Re]

On Sun, Sep 12, 2010 at 07:30:05PM +0200, yy wrote:
>
> 2010/9/12 Lucio De Re <lucio@proxima.alt.za>:
> > My thinking is that 9vx could start up as root
> > [ ... ]
>
> The advantage of the tap device is precisely that it does not need
> root permissions. You need those permissions to manage the devices,
> but that will be normally done by tunctl or openvpn. Those are the
> programs that have to worry about being run as root, not 9vx. In other
> words: you need to be root to create the tap device, but not to use
> it.
>
I eventually got that far :-)
I do appreciate confirmation of my understanding and I now understand
the underlying processes considerably better.

> > And if anybody can arrange a short lesson on using networking under 9vx,
> > that would also be greatly appreciated.
>
> Inside 9vx, networking with tap devices is not different to using
> physical devices. At the host system level, it works as it does in
> qemu (there could be more bugs though). There are many qemu tutorials
> with sample scripts and better explanations than what I could give.

I'll check on qemu, I haven't tried it with any success (or real effort,
for that matter) in the past, but then I also had even less understanding
than I have now.

> The particular configuration I'm using is documented at:
>
> http://wiki.archlinux.org/index.php/QEMU#Tap_Networking_with_QEMU
>
> Based on the qemu-ifup/down scripts described there I wrote a 9vx-tap
> script you can find at:
>
> http://bitbucket.org/yiyus/vx32/src/tip/src/9vx/9vx-tap
>
> Probably disecting that script is the best way to understand how the
> bridge, the tap devices and 9vx play together.
>
It's very, very helpful.  I would, and almost certainly will, have
split the "tunnel" and "openvpn" portions into two scripts (a selector
of some type might be good enough, but isn't easily justified), because
I'm sure that they don't overlap quite the way the present shape of the
script suggests.  I found it after posting my request, I still haven't
got everything working to my satisfaction, but I think the reference to
qemu will help.

There are still questions unanswered: (1) would switching userid be
useful and practical, irrespective of the actual need for it? and (2)
would it make sense to migrate the virtual network devices to vx32?
I'm quite happy to entertain opinions, that's all I have to work with
right now, it takes me a long time to read and understand source code :-(

I know that Ron has already replied to the first of these questions,
I'm hoping that those who made the original decisions will contribute
their rationales as well.

++L

PS: and thanks to all those who have contributed to such a superb toolkit.

Re: [9fans] 9vx/vx32 - Out of ignorance

[Lucio De Re]

On Sun, Sep 12, 2010 at 12:27:07PM -0700, Bakul Shah wrote:
>
> On a mac you don't need root perms to open a tap device.

This is sorted out to my satisfaction, thank you.

>
>   Here you have two choices:
>
I think I lack some of the terminology to get my mind around all this,
but some experimenting will definitely help me figure it out.  And 9vx
is very helpful in being robust and quick.  Just to explain my problem,
I can run 9vx as a terminal to each of two cpu/everything servers, but
I can't (yet) attach the other fileserver when attached to either of
them (they are configured very similarly).

Somehow, in all the information provided so far I'm sure there is enough
detail for me to make the final step, I just have to study what I have
a little longer.

So, thanks everyone.

++L

Re: [9fans] 9vx/vx32 - Out of ignorance

[yy]

2010/9/12 Lucio De Re <lucio@proxima.alt.za>:
> It's very, very helpful.  I would, and almost certainly will, have
> split the "tunnel" and "openvpn" portions into two scripts (a selector
> of some type might be good enough, but isn't easily justified), because
> I'm sure that they don't overlap quite the way the present shape of the
> script suggests.  I found it after posting my request, I still haven't
> got everything working to my satisfaction, but I think the reference to
> qemu will help.

The 9vx-tap script is quite naive. I decided to leave it that way
because its purpose is more to serve as documentation than as
something you will actually use. It is the simplest script I could
come up with, but can be improved in many ways.

> There are still questions unanswered: (1) would switching userid be
> useful and practical, irrespective of the actual need for it?

I'm not sure why you would want to do that, but I'm with ron: if you
are interested, go ahead.

> and (2)
> would it make sense to migrate the virtual network devices to vx32?

Why? The network devices are actually quite simple, and I guess you
could move the core to libvx32, but I don't know what you gain with
that. As I see it, I like the current situation where vx32 is a
sandboxing library and 9vx takes care of providing the virtual
devices.

-- 
- yiyus || JGL . 4l77.com