Re: [libvirt] New QEMU daemon for persistent reservations

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.