[libvirt] New QEMU daemon for persistent reservations

Michal Privoznik mprivozn at redhat.com
Mon Nov 27 13:35:29 UTC 2017


On 11/27/2017 02:29 PM, Daniel P. Berrange wrote:
> On Mon, Nov 27, 2017 at 02:01:06PM +0100, Paolo Bonzini wrote:
>> On 27/11/2017 13:57, Daniel P. Berrange wrote:
>>>> Got it.  My problem here is that ioctl permission might be too strict.
>>>> One use case for the helper is to bypass the ioctl permission, and only
>>>> grant SCSI passthrough access for the specific case of persistent
>>>> reservation commands.  Would it make sense to also allow e.g. "lock"
>>>> (and would it pass the SELinux policy)?
>>> When I write "...ioctl perm..." I use that just as a short cut to represent
>>> whatever SELinux access vector would be checked if QEMU were to do the SCSI
>>> PR calls itself.  The access vector permission bits are defined in the policy
>>> file, and in the auto-generated header file /usr/include/selinux/av_permissions.h
>>>
>>> AFAICT, there's only a coarse COMMON_FILE_IOCTL access vector defined, nothing
>>> on the level of individual ioctl commands. So, yes, the MAC policy check
>>> would allow other ioctl commands to be run, aside from those required for
>>> persistent reservations. We just have to rely on the PR helper code for
>>> that restriction.
>>
>> But can you also test _more_ permissions if you want?  So if QEMU passed
>> to the helper a file for which it has "lock" but not "ioctl" access,
>> would it make sense for the helper to let it through?  Together with the
>> socket MAC, this should be precise enough.
> 
> Sure, you can check any of the permissions which are defined for the
> type of object you've got. The goal is to check permissions which
> correspond to actions you're taking on the object. So if you do
> something other than just ioctl() on the passed in FD, it would make
> sense to check further permissions as appropriate.

Just to make sure I understand correctly: the PD passing is done by qemu
and not libvirt, right? Technically, we don't open the disks.

Michal




More information about the libvir-list mailing list