[libvirt-users] Which objects does dynamic_ownership apply to?

[Milan Zamazal]

Michal Privoznik <mprivozn at redhat.com> writes:

> On 09/20/2018 12:31 PM, Milan Zamazal wrote:
>> Michal Prívozník <mprivozn at redhat.com> writes:
>> 
>
>>> On 09/19/2018 12:39 PM, Milan Zamazal wrote:
>>>> Hi, I'm playing with dynamic ownership and not all objects have their
>>>> owners changed.
>>>
>>>>
>>>> Is dynamic_ownership and its scope documented somewhere, besides the
>>>> comment in qemu.conf?
>>>>
>>>> And what kinds of objects are handled by dynamic ownership?  While some
>>>> objects seem to be handled, other objects are apparently unaffected.
>>>> For instance /dev/hwrng or a USB host device keep their root owners and
>>>> are inaccessible to the VM.  Is that expected or do I have anything
>>>> wrong?
>>>
>>> Basically, if a file is used solely by a domain we can relabel it.
>>> However, if a file can be used by other processes (not only qemu) then
>>> we must not change its label as we would be effectively cutting of the
>>> other processes we know nothing about. In this case, /dev/hwrng might be
>>> used by some other process in the system. Also the fact that it's owned
>>> by root:root and not readable by anybody except the root user, tells me
>>> that we might not want to pass the file to any domain?
>> 
>> Well, /dev/hwrng may be arguable, although oVirt permits passing it to a
>> VM, of course only on explicit user's request.
>> 
>> But how about host devices such as USB and PCI devices?  For example
>> 
>>   <hostdev managed="no" mode="subsystem" type="usb">
>>       <source>
>>           <address bus="3" device="2" />
>>       </source>
>>       <alias name="ua-3773b389-54be-4fd5-ae8b-2f954470b1a9" />
>>       <address bus="0" port="1" type="usb" />
>>   </hostdev>
>> 
>> doesn't change the owner of /dev/bus/usb/003/002 (the same for
>> managed="yes"). 
>
> Are you perhaps using namespaces and looking into the parent namespace
> rather than into qemu namespace?

Ah, that's the trick, thank you!

>  Similarly for a PCI hostdev device /dev/vfio/* owners
>> are not changed.  Does the same argument apply?
>
> Again, try looking into the namespace.
>
>> 
>> OTOH, a CD-ROM image, which can be shared across domains and at least in
>> theory can be accessed by other processes, gets its owner changed.
>
> Well, this is arguable. Firstly, if you want CD-ROM image to be shared,
> it needs to have <shareable/> tag, and you may want to either disable
> relabelling by <seclabel relabel='no'/> or ensure by other ways that all
> qemu processes are able to access it.

OK, makes sense.

> Libvirt should not get involved into coming up with a seclabel that
> would fit all. In terms of unix uid:gid - libvirt should not try to
> figure out which users belong to which groups and try to find such
> combination that would fit all. This is sysadmin's responsibility.

Sure.

>> My primary concern right now is what exactly is handled.  We can deal
>> with manual ownership changes of certain devices as we have done so far.
>> But I'm looking for a more reliable source of information than my
>> experiments, to prevent future breakages.  Is it documented anywhere
>> what is handled by libvirt and what is not?  Or can it be defined in
>> less ambiguous terms than above?
>
> What devices are you changing yourself? We definitely need to go through
> the list and evaluate every item.

USB/SCSI/PCI/mediated host devices – I assume it was just my confusion
of not being aware of the namespace and they should work.

And then hwrng, which definitely doesn't work (QEMU fails on start due
to not being able to access it).  We can change the owner in oVirt,
since the host is not supposed to be used for purposes other than
running VMs.  I can understand that doesn't apply in all situations.
But if someone passes /dev/hwrng to a VM, it's intended to be accessible
there.  Should libvirt or sysadmin be responsible for that?  (I'd vote
for libvirt in order to get rid of the udev rule based workaround in
oVirt, but maybe there are more important arguments to consider.)

Thanks,
Milan