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@xxxxxxxxxxxxxxxxx/thread/2NR3NUK7H3IUQBGM5NHWOHFV5TPT6QGE/
--
Andrea Bolognani / Red Hat / Virtualization
