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

[Milan Zamazal]

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?

Thanks,
Milan

[Michal Prívozník]

Post by Milan Zamazal
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?

Michal

[Milan Zamazal]

Post by Michal Prívozník

Post by Milan Zamazal
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"). Similarly for a PCI hostdev device /dev/vfio/* owners
are not changed. Does the same argument apply?

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.

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?

Thanks,
Milan

[Michal Privoznik]

Post by Milan Zamazal

Post by Michal Prívozník

Post by Milan Zamazal
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

Post by Milan Zamazal
are not changed. Does the same argument apply?

Again, try looking into the namespace.

Post by Milan Zamazal
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.

Post by Milan Zamazal
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.

Michal

[Milan Zamazal]

Post by Michal Privoznik

Post by Milan Zamazal

Post by Michal Prívozník

Post by Milan Zamazal
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!

Post by Michal Privoznik
Similarly for a PCI hostdev device /dev/vfio/* owners

Post by Milan Zamazal
are not changed. Does the same argument apply?

Again, try looking into the namespace.

Post by Milan Zamazal
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.

Post by Michal Privoznik
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.

Post by Michal Privoznik

Post by Milan Zamazal
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