[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GSoC: the plan for the project network virtualization
From: |
olafBuddenhagen |
Subject: |
Re: GSoC: the plan for the project network virtualization |
Date: |
Fri, 4 Jul 2008 23:51:12 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
Hi,
On Fri, Jul 04, 2008 at 12:24:56AM +0200, zhengda wrote:
> olafBuddenhagen@gmx.net wrote:
> So if I'm right, the filter translator has to implement the RPC in
> device.defs to communicate with the client and it calls the RPC to
> communicate with the multiplexer.
Yes. The filter simply proxies the interface it is attached to.
> the filter translator actually doesn't have to be used with the
> multiplexer in every case. We use it only for enforcing policies.
Exactly.
> The only situation I think it can be used is that a user's
> multiplexer or a pfinet server opens a virtual network interface
> created by the root's multiplexer (so the user's multiplexer can
> access the external network). The filter translator doesn't need to
> sit on the user's multiplexer.
Well, depends on the use case. The user might want to enforce policies
on his own clients, too.
>>> > "root could delegate access to the real network interface, and the
>>> > user could run a hypervisor"? How do we do it? create another
>>> > program that is run by root and that communicates with the
>>> > hypervisor?
>>
>> To be honest, I don't know the details. In a capability system, it
>> should always be trivial to delegate access to something. But I do
>> fear that the Mach device interface does not really fit there -- that
>> it's not possible to directly hand out a capability for a single
>> kernel device. If that is the case, we would again need a proxy for
>> the master device port, which would forward open() on the network
>> device, but block all others.
> If a proxy can help the user's multiplexer open the network interface,
> I wonder who can control the traffic from the user's multiplexer.
Mind the context: I was talking here about the specific case where root
wants to give the user full access to a real network interface.
In other cases, where more limited access is desired, root would set a
filter of course.
Admittedly, giving full access can be considered a special case of
giving limited access -- namely with an all-pass filter... But that's
not very efficient :-) (At least in the simple implementation.)
> I think it's better to run a multiplexer by the root on the real
> network interface and the traffic control is done by the filter
> translator running on the virtual interface provided by the root's
> multiplexer.
Note that it's not strictly necessary for root to run a multiplexer. To
enforce policies, it is sufficient to set the filters directly on the
real network interface. The multiplexer is necessary only to allow
routing between different clients...
-antrik-