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?

On 09/20/2018 12:31 PM, Milan Zamazal wrote: > Michal Prívozník <mprivozn(a)redhat.com&gt; 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?

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.

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.

> 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.