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