Re: [libvirt] [PATCH v2] qemu: Introduce caching whether /dev/kvm is accessible
On 10/30/2018 04:07 PM, Daniel P. Berrangé wrote:
On Tue, Oct 30, 2018 at 03:45:36PM +0100, Michal Privoznik wrote:
> On 10/30/2018 02:46 PM, Michal Privoznik wrote:
>> On 10/30/2018 01:55 PM, Daniel P. Berrangé wrote:
>>> On Tue, Oct 30, 2018 at 10:32:08AM +0000, Daniel P. Berrangé wrote:
>>>> On Tue, Oct 30, 2018 at 11:08:45AM +0100, Michal Privoznik wrote:
>>>>> On 10/30/2018 10:35 AM, Daniel P. Berrangé wrote:
>>>>>> On Tue, Oct 30, 2018 at 09:13:50AM +0100, Michal Privoznik
wrote:
>>>>>>> On 10/29/2018 06:34 PM, Marc Hartmayer wrote:
>>>>>>>> Introduce caching whether /dev/kvm is usable as the QEMU
user:QEMU
>>>>>>>> group. This reduces the overhead of the QEMU capabilities
cache
>>>>>>>> lookup. Before this patch there were many fork() calls
used for
>>>>>>>> checking whether /dev/kvm is accessible. Now we store the
result
>>>>>>>> whether /dev/kvm is accessible or not and we only need to
re-run the
>>>>>>>> virFileAccessibleAs check if the ctime of /dev/kvm has
changed.
>>>>>>>>
>>>>>>>> Suggested-by: Daniel P. Berrangé
<berrange(a)redhat.com>
>>>>>>>> Signed-off-by: Marc Hartmayer
<mhartmay(a)linux.ibm.com>
>>>>>>>> ---
>>>>>>>> src/qemu/qemu_capabilities.c | 54
++++++++++++++++++++++++++++++++++--
>>>>>>>> 1 file changed, 52 insertions(+), 2 deletions(-)
>>>>>>>>
Not really. Udev is in use everywhere, so this behaviour makes the
patch useless in practice, even though it is technically right in
theory :-(
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.
Honestly, I don't have solution.
Michal