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

[Eric Blake]

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

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120119/77e5b567/attachment-0001.sig>