On Thu, Sep 17, 2009 at 02:14:06PM +0200, Arnd Bergmann wrote:
> On Thursday 17 September 2009, Michael S. Tsirkin wrote:
> > On Thu, Sep 17, 2009 at 01:30:00PM +0200, Arnd Bergmann wrote:
> > > On Wednesday 16 September 2009, Michael S. Tsirkin wrote:
> > > > > Also, I might not want to allow the user to open a
> > > > > random random raw socket, but only one on a specific downstream
> > > > > port of a macvlan interface, so I can filter out the data from
> > > > > that respective MAC address in an external switch.
> > > > 
> > > > I agree. Maybe we can fix that for raw sockets, want me to
> > > > add it to the list? :)
> > > 
> > > So far, I could not find any theoretical solution how to fix this,
> > 
> > What if socket had a LOCKBIND ioctl after which you can not bind it to
> > any other device?  Then someone with RAW capability can open the socket,
> > bind to device and hand it to you. You can send packets but not
> > switch to another device.
> 
> Could work, though I was hoping for a solution that does not depend
> on a priviledged task at run time to open the socket, as you have with
> persistant tap devices or chardevs like macvtap that can have their
> persissions set by udev.
> 
> 
>       Arnd <><

Well, we could have a char device with an ioctl that gives you back a socket,
or maybe even have it give you back a socket when you open it.
Will that make you happy?

-- 
MST
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to