[libvirt] [PATCH v2] qemu: Introduce caching whether /dev/kvm is accessible

Ján Tomko jtomko at redhat.com
Thu Nov 1 04:11:30 UTC 2018


On Tue, Oct 30, 2018 at 03:53:59PM +0000, Daniel P. Berrangé wrote:
>On Tue, Oct 30, 2018 at 04:47:32PM +0100, Michal Privoznik wrote:
>> Well, caching owner + seclabels + ACLs won't help either. What if user
>> loads some profile into AppArmor or something that denies previously
>> allowed access to /dev/kvm (or vice versa)? What I am saying is that
>> there are some security models which base their decisions on something
>> else than file attributes.
>
>The virFileAccessibleAs check for /dev/kvm was put in their to ensure
>that we correctly report usability of KVM in the capabilities XML
>according to file permissions/ownership. Essentially KVM is not usable
>until the udev rule is applied to change permissions to world accessible
>or to set the kvm group.
>

Can libvirt be run sooner than the permissions are set up during regular
start-up, or this is just for the case of the user randomly touching the
permissions?

IIRC the problem was that users with vmx disabled in BIOS setup needed
to delete libvirt's qemuCaps cache manually after enabling it even after
restarting the system.
To catch that, all we'd have to do is run the check once per daemon
lifetime,

>I don't think we need to care aout selinux/apparmor restrictions - just
>need to be no worse than what we cope with today, which is just perms
>and owner/group.

but that could be considered worse according to this metric.

Jano
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20181101/9b23cf7b/attachment-0001.sig>


More information about the libvir-list mailing list