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

[Paolo Bonzini]

On 01/19/2012 10:48 PM, Eric Blake 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;

Indeed, and using CAP_SYS_RAWIO might let guests brick your disks by 
doing firmware updates.

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

I don't even see the need to add an attribute to the <disk> element.  I 
think it's wrong, because you cannot set CAP_SYS_RAWIO for only one 
disk.  It's a per process decision.

I think Taku's current approach is the right one.

Paolo