[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [PATCH v3 0/5] RFC: grant KVM guests retain arbitrary capabilities



On Thu, 19 Jan 2012 14:48:41 -0700
Eric Blake <eblake redhat com> wrote:

> On 01/19/2012 02:10 PM, Daniel P. Berrange wrote:
> > On Thu, Jan 19, 2012 at 01:32:08PM -0700, Eric Blake wrote:
> >> On 01/18/2012 12:38 AM, Taku Izumi wrote:
> >>>> I am now wondering if we should do this in a different way. ie if
> >>>> there is some XML configuration parameter for the <disk> that 
> >>>> indicates the need for rawio, then libvirt could automatically
> >>>> ensures that we add CAP_SYS_RAWIO when starting QEMU.
> >>>
> >>>    I see.
> >>>    You say if a guest has the following XML configuration,
> >>>    "CAP_SYS_RAWIO" capability is automatically added to it, right?
> >>>   
> >>>      <disk type='block' device='lun'>
> >>
> >> Yes, that actually seems reasonable, especially since device='lun' is
> >> brand new, and so far, is really the only reason that we'd need
> >> CAP_SYS_RAWIO.
> > 
> > Does device='lun' really require CAP_SYS_RAWIO ?  I hadn't seen that
> > mentioned before now
> 
> My understanding (and hopefully Paolo corrects me if I'm wrong) is that
> some, but not all, SG_IO ioctl usage patterns require CAP_SYS_RAWIO;
> using device='lun' is what allows any SG_IO ioctl to pass through in the
> first place, but then there is further validation based on the
> capabilities.  So maybe this calls for an additional xml attribute, only
> needed for device='lun', that controls whether the cap is also desired
> when accessing the pass-through block device:
> 
> <disk type='block' device='lun' rawio='enabled'>
> 
> rather than always blindly granting CAP_SYS_RAWIO merely because of the
> presence of device='lun'.


 OK. I'll try to implement like this way.

-- 
Taku Izumi <izumi taku jp fujitsu com>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]