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. Thanks, Paolo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
