Hi, On Fri, Jul 04, 2008 at 12:24:56AM +0200, zhengda wrote: > [EMAIL PROTECTED] 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-
