On Fri, Jul 05, 2024 at 12:38:36PM GMT, Christian Ehrhardt wrote:
That is due to the check for valid_path having /usr/share/OVMF/ in
restricted_rw and therefore blocking this. Now the question is,
was this meant to allow using the system files RW - then I think
it is rightfully blocked. Instead I'm going to assume this was meant for
separate files.
# TEST ONLY - DO NOT DO THIS
$ cp /usr/share/OVMF/OVMF_CODE_4M.fd /opt/OVMF_CODE_4M.fd
$ chmod 666 /opt/OVMF_CODE_4M.fd
root@o:~# virsh dumpxml testdomain | grep OVMF; uuid=$(virsh domuuid
testdomain); cat /etc/apparmor.d/libvirt/libvirt-${uuid}.files | grep OVM
<loader readonly='no'
type='pflash'>/opt/OVMF_CODE_4M.fd</loader>
"/opt/OVMF_CODE_4M.fd" rwk,
So we can see the code achieves what it is intended to do while not
regressing the former flow.
But it can not be used on the normal paths, that is probably good to avoid
accidentally overwriting these.
We definitely don't want the shared CODE files to be used in
read/write mode, as that would certainly cause corruption.
In fact, I would have expected such a request on the user's part to
be outright rejected by libvirt, but when I tried I realized that
wasn't the case, at least in some scenarios. I've just posted some
patches[1] that should improve the situation.
But I think along the patch we should hear a little bit more about
the use
case
to ensure that it has a practical use?
@Miroslav: how exactly would you make use of that now?
Yes, it would be nice to get confirmation.
[1]
https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/2N...
--
Andrea Bolognani / Red Hat / Virtualization