Re: [libvirt] [PATCH v2] qemu: Introduce caching whether /dev/kvm is accessible
On 11/01/2018 05:11 AM, Ján Tomko wrote:
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?
Sure it can. And it is. For instance, I have ConsoleKit installed on my
system and when I log in as a regular user into my system, it adds an
ACL entry to /dev/kvm to allow access to the user. Libvirtd is already
running at that point (well, except not really because I don't run it as
a service since I'm running it from git all the time. But you get the
picture).
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.
Sounds like it. The commit that introduced the check is d87df9bd39b.
Honestly, I don't think we need to care about perms - we can assume
those are set properly (as they don't change often). What we have to
care about is inserting/removing kvm module (even though it's not
necessary these days since virtualbox has learned how to co-exist with
KVM).
Michal