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

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'.