libvirt restore exactly the old ownership of images

I don't think it would be safe at any rate to have the ISO images be
written to while kvm is reading them. Would it be ok to work around
this another way?

Perhaps the right way to update the ISOs is:

 cp orig.iso new.iso
 rsync -Pv mirror://updated_iso.iso new.iso
 rm orig.iso
 mv new.iso orig.iso

This way you can still minimize network traffic, while syncing to a
temporary copy. After the 'rm orig.iso', libvirt and kvm will
continue to use the original, deleted file, until they close it.
Then, the next time they open 'orig.iso', they'll get the new file.

Would that be conceivable with your mirroring setup?

Yes, this would work (as long as the process doing this move owns the directory -- otherwise it is still an error 13). The whole point, though, is that libvirt does not need to take ownership of a *read-only* file.

At least it could revert the ownership when the VM is closed, if you want to protect against an ISO update while the ISO is in use by libvirt. Or use flock, or something. But this (update-while-somebody-is-using) is a common issue on *IX, and still we do not see ownership being unilaterally changed.

Of course, we can also bypass by using 'sudo', but this would break the least privilege principle.

Serge, from what I understand of rsync, it never writes directly to the destination file, it will create a temporary hidden file and write to that, then unlink/rename when the transfer is complete.

So the steps can just be

rsync rsync://mirror/file.iso orig.iso

it won't interfere at all with anything that has the .iso opened.. it will be like any other unlinked open file.

This whole bug is about libvirt's DAC security driver. It will chown files to the user that kvm runs as. On Ubuntu, this is the libvirt-qemu:kvm user (adjustable via /etc/libvirt/qemu.conf). If you look at the ISO file, its ownership should have been changed to this user. The DAC security driver cannot be disabled like the other security drivers (eg AppArmor and SELinux), but is instead either used alone or with one other security driver (AppArmor on Ubuntu).

I believe that if libvirt is configured to run kvm as root, then the DAC driver will not chown files (because it doesn't have to-- with DAC root can read anything). This was the case on Lucid iirc. As a workaround, you should be able to configure /etc/libvirt/qemu.conf to use:
user = "root"
group = "root"

and the problem should go away (not tested on maverick or natty libvirt). Because kvm is still confined by AppArmor in this configuration, the security stance is not greatly diminished. This was the default in Lucid.

I've not looked at how well libvirt handles chowning files, but I imagine one reason why it works the way it does is if libvirt chowned back to the user, this is a potential race condition and security issue-- ie, libvirt chowns the ISO to libvirt-qemu:kvm, then starts the machine. Now I hard link the ISO to /etc/shadow and shutdown the machine. libvirt chowns /etc/shadow to my user and group. Granted, members of the libvirtd group (ie access to qemu:///system) are considered privileged anyway (they have access to raw disks among other things), but with the above described scenario, it is far too easy to escalate privileges. Chowning to libvirt-qemu:kvm is potentially problematic as well, but the hard link to /etc/shadow is less interesting there since the user isn't libvirt-qemu and the kvm group membership doesn't gain you as much (setgid should be stripped on chgrp in Linux, and group writable files are not as common (though there are a few that are interesting)). Natty has some kernel protections that could help here, but they are upstream and upstream libvirt would not be able to rely on them being present.

@Clint: zsync does the same (writes the updated file to a temp, then renames/unlinks/whatever -- did not check the source).

@Jamie: I just tried with qemu.conf setting user/group to root -- the ISO gets chown-ed to root:root, 0600. So, no dice here. Nevertheless, my whole point is it does not make much sense, security-wise, to chown a read-only file: it is an ISO image, and it is mounted on the CDROM:

        <devices>
                <disk type='file' device='disk'>
                        <driver name='qemu' type='qcow2'/>
                        <source file='/var/lib/ubuntu-server-iso-testing/tests/819f2dd9-0041-48aa-8dfe-c5899f2cafe7/disk1.qcow2'/>
                        <target dev='vda' bus='virtio'/>
                </disk>
                <disk type='file' device='cdrom'>
                        <source file='/var/lib/ubuntu-server-iso-testing/isos/ubuntu-server/natty-server-amd64.iso'/>
                        <target dev='hdc'/><readonly/>
                </disk>
(...)
        </devices>

If the file is never chown-ed to libvirt:kvm/whatever, then there is no race -- the file will keep the current ownership. Obviously, this does not apply to the qcow2 disc -- there is a clear exposure there. Now, why does libvirt in user-mode also chown the discs? I would expect the user-mode to run under the control (and ownership, at least for the disc images) of the effective userId that started the VM.

A correction on the above "I just tried with qemu.conf setting user/group to root -- the ISO gets chown-ed to root:root, 0600.": Actually, the permissions are kept as they were.

So does that suffice for your needs?

Actually, no... theonly change is the owner got to be root, from libvirt. I still am not convinced a read-only ISO has to be chown-ed to the libvirt account.

I intend to write a patch to make this behavior an option, and send it to the libvirt list for comment.

A package with the proposed fix is available for natty in ppa:serge-hallyn/virt. If this does what you need, then we can proceed to talk to the libvirt community.

Thank you, Serge. Testing it now.

It seems the ISOs are hosed right now, I get a sudden reboot in the basic package install. But -- as far as this bug is concerned -- the ISOs ownership are maintained on the original owner.

Perfect, Serge.

Re-verified the bug and the patch, and sent the patch to the upstream mailing list:

https://www.redhat.com/archives/libvir-list/2011-September/msg00458.html

If upstream rejects this, then I will mark the bug wontfix.

See https://www.redhat.com/archives/libvir-list/2011-October/msg00104.html and https://www.redhat.com/archives/libvir-list/2011-October/msg00110.html for the upstream response. The first message describes the proper fix (switching from chown to acls in the dac security code). The second suggests using a readonly mount for the isos.

Is it possible to use a read-only bind mount of the mirror directory for your libvirt VMs? You can either mount it elsewhere, or else have /etc/init/libvirt unshare a new mount namespace and remount the mirror directory read-only in place before starting libvirtd.

yes, I can set a readonly mount. Will have it set in a few. Thank you, Serge.

This really feels like a serious security bug. The whole point of running qemu as non root is to prevent it from accessing files that you haven't given it permission to. By blindly chowning files to the qemu user, you allow for the user who is given permission to run virtual machines to start one with direct access to your /boot partition and hack the host system.

Even if you do wish to bypass permissions and allow the vm access to whatever file a vm admin has configured it to ( under the assumption that they are trusted as if root ), you don't do that with the sledge hammer of chowning the file; you open the file while still root, and pass the open file descriptor to qemu.

Really, it should assume the identity of the user who is requesting that the vm be started and open the file as them rather than root, thus restricting access only to the files that user has access to, but that may be considered a separate issue.

For now I will focus on at least getting rid of the bad behavior of permanently chowning files.

It's exceptionally frustrating.

It's been a while since it was solved upstream such that when a domain is terminated, the image ownership gets restored to what it was when the domain was launched. However, the way it tracks the original ownership is by storing it in xattr's of the image... but we've been passing --without-attr since 2014, due to a test failure on the Debian buildd's, and without attr, no ownership memory.

Back when it was added I guess it didn't make much of a difference, but now it's preventing this bug from being solved. The package builds just fine on our buildd's (at least in my PPA).

Attached debdiff to fix this.

Interesting indeed.
I remember the patch to restore file ownership, and at least in the cases I looked at it worked fine.
I'm using the normal Ubuntu libvirt in Focal

ii libvirt-daemon 6.0.0-0ubuntu8.1 amd64 Virtualization daemon

That is built without attr support as Soren outlined, a buildlog is here [1]

But with that build it clearly sets and restores file ownership in the common default case:

$ sudo ls -laF /var/lib/libvirt/images/ubuntu18.04.qcow2; virsh start ubuntu18.04; sleep 30s; sudo ls -laF /var/lib/libvirt/images/ubuntu18.04.qcow2; virsh shutdown ubuntu18.04; sleep 30s; sudo ls -laF /var/lib/libvirt/images/ubuntu18.04.qcow2

-rw------- 1 root root 16108814336 Mai 11 14:34 /var/lib/libvirt/images/ubuntu18.04.qcow2
Domain ubuntu18.04 started

-rw------- 1 libvirt-qemu kvm 16108814336 Jun 22 13:02 /var/lib/libvirt/images/ubuntu18.04.qcow2
Domain ubuntu18.04 is being shutdown

-rw------- 1 root root 16108814336 Jun 22 13:03 /var/lib/libvirt/images/ubuntu18.04.qcow2

Just as I remember, file ownership is restored using a build that had --without-attr.

Config for that is in /etc/libvirt/qemu.conf and defaults to
  #dynamic_ownership = 1

Code wise
 This is around virSecurityDACSetOwnership and virSecurityDACRestoreFileLabelInternal.
 I see the xattr store that you mentioned being used in virSecurityGetRememberedLabel
 which would fill the content as you reported.

VIR_SECURITY_MANAGER_DYNAMIC_OWNERSHIP
VIR_FILE_OPEN_FORCE_OWNER

To be clear - I'm not even against enabling attr support it is in main and should be fine, but we have to resolve why it seems to be important for your case but isn't otherwise.

Ok, maybe it generally is only ok because in 99% of the cases the default of root:root was what it began with.
Changing my image and retrying.

$ sudo ls -laF /var/lib/libvirt/images/ubuntu18.04.qcow2; virsh start ubuntu18.04; sleep 30s; sudo ls -laF /var/lib/libvirt/images/ubuntu18.04.qcow2; virsh shutdown ubuntu18.04; sleep 30s; sudo ls -laF /var/lib/libvirt/images/ubuntu18.04.qcow2
-rw------- 1 paelzer root 16108814336 Jun 22 13:27 /var/lib/libvirt/images/ubuntu18.04.qcow2
Domain ubuntu18.04 started

-rw------- 1 libvirt-qemu kvm 16108814336 Jun 22 13:28 /var/lib/libvirt/images/ubuntu18.04.qcow2
Domain ubuntu18.04 is being shutdown

-rw------- 1 root root 16108814336 Jun 22 13:28 /var/lib/libvirt/images/ubuntu18.04.qcow2

Ok, now things make sense.
And as I said libattr1 is in main, the error conditions if the underlying FS has no libattr support are covered by the libvirt code I think. While the impacts as an SRU to existing versions is unclear I agree that we should look into enabling this in >=20.10

[1]: https://launchpad.net/ubuntu/+source/libvirt/6.0.0-0ubuntu8.1/+build/19398123

Extra comment to not be lost - thanks Soren for the hint.

Note, this will be part of the libvirt merge (including all sorts of regression checks) which will be late July/early August.

A non-root process that uses qemu:///system to run virtual machines (which is required for most network configurations) will lose access to its disk images for good as soon as the domain is started.

First it'll be changed to libvirt-qemu:kvm and once the domain is terminated it will be set to root:root. As a regular user this is nuisance that can be worked around with "sudo chown" (the vast majority of users have this access), but for a daemon that doesn't run as root and doesn't have a human to take care of it and needs access to *its own* disk images, this makes libvirtd as shipped by ubuntu unusable.

I'd highly suggest an SRU for this.

I've been away from Ubuntu development for a while. Is there any particular reason not to just upload the fixed version now?

To clarify, I meant: Is there any particular reason to not just upload this fix *to Groovy* now? I know an SRU needs validation first.

Hi Soren,
yeah I've seen your old youtube video on what is new in virtualization for Ubuntu since the name felt known :-).

The reason to not upload immediately is that I'd want to see if there are any other bad effects of attr being enabled that we might miss.
I'd want to see if e.g. migrations on disk images on shared storage run into trouble or something like that. To do so I'd run a bunch of regression tests in addition to what comes to my mind for this case in particular. Those tests need quite some time and allocation of systems - therefore they are most effective if coupled with a bunch of other big changes where the tests will cover "more new code".

In addition I'm away for quite some time in July, so if I break things with an upload now I'm not around to clean up my mess.

And while the bug feels bad, it was open so long attracting only so few people/reports that while it feels important for the two of us now it might overall be not too urgent to squeeze it in asap.

I hope that explains why I have postponed the change to when I get to merge a newer libvirt for groovy anyway.

Gosh. I'd happily forgotten about that video. I was so young and so mumbly. :D

I'm not sure I understand. If you're not uploading to groovy, how are you collecting test results?

Also, I don't know what sort of test facilities or processes you have available, so I don't know how time consuming or expensive a complete regression test run is, but in general I find that smaller changes are better than larger, batched changes for finding problems and identifying their cause. If something doesn't work after pushing a big batch of changes, it can be really hard to identify which one of the many changes is the culprit.

I upload to a PPA and test against that when doing bigger changes.
Only when everything works there the same thing is uploaded to the -dev release.

I agree to the "many small changes" theory in general, except for things that either:
- a) are used in many other tests (which means breaking these breaks a lot)
or
- b) require a rather intensive testing (then there is an efficiency gain to batch to some extend)

In this case it is even a+b which makes me be careful.
If not for me being away in 10 days for a while I'd not be too concerned as it could be reverted.
You know what, I can throw it in a PPA and if magically everything works fine (after all most tests are automated - it is all the special cases that might happen which make this a real effort) without hickups I'll consider an earlier upload.

Consider it a favor for your old work :-)
I'll let you know how things turn out ...

We are lucky - tests that ran over night LGTM nothing happened.
In the meantime MP [1] review by the team also completed.

[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/386212

Uploaded to groovy

This bug was fixed in the package libvirt - 6.0.0-0ubuntu10

---------------
libvirt (6.0.0-0ubuntu10) groovy; urgency=medium

  * enable attr support to store XATTR labels. Among other things
    this allows to properly restore file ownership (LP: #691590)
      - d/control: build depend to libattr1-dev
      - d/rules: configure --with-attr

 -- Christian Ehrhardt <email address hidden> Mon, 22 Jun 2020 21:30:50 +0200

I think this won't fit for a SRU into a long released release like Bionic.
But for Focal I'd think this still makes sense IMHO - it is a behavior change yes, but a wanted one.

I'll prepare an upload for Focal ...

MP: https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/386376

Uploaded to focal-unapproved for the SRU team to evaluate and sent to Debian [1].

[1]: https://salsa.debian.org/libvirt-team/libvirt/-/merge_requests/52

Hello C, or anyone else affected,

Accepted libvirt into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libvirt/6.0.0-0ubuntu8.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-focal. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

The key SRU user impact justification I wanted I found in Soren's comment 27 - thank you.

Can I request that both the "filesystem supporting xattr" and "no filesystem xattr support" cases be verified for expected behaviour please?

Since we're changing behaviour I'm also concerned that this is high risk of regression for some use case we haven't considered where the previous behaviour is being depended upon. Thoughts on how to mitigate this would be appreciated. I appreciate that Christian has already come up with and tested a variety of use cases here - how comprehensive do you think these are when compared to "weird" things users might be doing?

All autopkgtests for the newly accepted libvirt (6.0.0-0ubuntu8.2) for focal have finished running.
The following regressions have been reported in tests triggered by the package:

libvirt-dbus/1.3.0-1 (armhf)
libvirt/6.0.0-0ubuntu8.2 (amd64)

Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-migration/focal/update_excuses.html#libvirt

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

Hi Robie,
about:
"Since we're changing behaviour I'm also concerned that this is high risk of regression for some use case we haven't considered where the previous behaviour is being depended upon. Thoughts on how to mitigate this would be appreciated. I appreciate that Christian has already come up with and tested a variety of use cases here - how comprehensive do you think these are when compared to "weird" things users might be doing?"

Answer: the current workaround would server there as well, one can tweak in file /etc/libvirt/qemu.conf
  # Whether libvirt should dynamically change file ownership
  # to match the configured user/group above. Defaults to 1.
  # Set to 0 to disable file ownership changes.
  #dynamic_ownership = 1

Currently this is enabled, changing the file to the runtime perms needed and then back (the bug) to root.
If you just chown the files to root and disable this feature it will match the former behavior (which now restores the proper former owner).

FYI: Flaky Autopkgtests resolved and good now.

Verification:
The problem
$ sudo chown root:kvm /var/lib/uvtool/libvirt/images/focal-ipxe.qcow
[sudo] password for paelzer:
[✓]─[paelzer@Keschdeichel ~]──[145208]──[12:57 Do Jul 16]──
$ ll /var/lib/uvtool/libvirt/images/focal-ipxe.qcow
-rw------- 1 root kvm 2546794496 Jul 16 12:57 /var/lib/uvtool/libvirt/images/focal-ipxe.qcow
[✓]─[paelzer@Keschdeichel ~]──[145209]──[12:57 Do Jul 16]──
$ virsh start focal-ipxe
Domain focal-ipxe started

[✓]─[paelzer@Keschdeichel ~]──[145210]──[12:57 Do Jul 16]──
$ ll /var/lib/uvtool/libvirt/images/focal-ipxe.qcow
-rw------- 1 libvirt-qemu kvm 2546794496 Jul 16 12:57 /var/lib/uvtool/libvirt/images/focal-ipxe.qcow
[✓]─[paelzer@Keschdeichel ~]──[145211]──[12:57 Do Jul 16]──
$ virsh shutdown focal-ipxe
Domain focal-ipxe is being shutdown

[✓]─[paelzer@Keschdeichel ~]──[145212]──[13:01 Do Jul 16]──
$ ll /var/lib/uvtool/libvirt/images/focal-ipxe.qcow
-rw------- 1 root root 2548105216 Jul 16 13:01 /var/lib/uvtool/libvirt/images/focal-ipxe.qcow

^^ didn't restore original ownership.

Install upgrade:
$ sudo apt install libvirt-daemon-system libvirt-clients
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following package was automatically installed and is no longer required:
  libllvm9
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
  libnss-libvirt libvirt-daemon libvirt-daemon-driver-qemu libvirt-daemon-driver-storage-rbd libvirt0
Suggested packages:
  libvirt-daemon-driver-lxc libvirt-daemon-driver-vbox libvirt-daemon-driver-xen libvirt-daemon-driver-storage-gluster libvirt-daemon-driver-storage-zfs auditd pm-utils systemtap
The following packages will be upgraded:
  libnss-libvirt libvirt-clients libvirt-daemon libvirt-daemon-driver-qemu libvirt-daemon-driver-storage-rbd libvirt-daemon-system libvirt0
7 upgraded, 0 newly installed, 0 to remove and 129 not upgraded.
Need to get 2.907 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://de.archive.ubuntu.com/ubuntu focal-proposed/universe amd64 libnss-libvirt amd64 6.0.0-0ubuntu8.2 [14,4 kB]
Get:2 http://de.archive.ubuntu.com/ubuntu focal-proposed/main amd64 libvirt-daemon-driver-qemu amd64 6.0.0-0ubuntu8.2 [605 kB]
Get:3 http://de.archive.ubuntu.com/ubuntu focal-proposed/main amd64 libvirt-daemon-driver-storage-rbd amd64 6.0.0-0ubuntu8.2 [28,3 kB]
Get:4 http://de.archive.ubuntu.com/ubuntu focal-proposed/main amd64 libvirt-daemon-system amd64 6.0.0-0ubuntu8.2 [67,5 kB]
Get:5 http://de.archive.ubuntu.com/ubuntu focal-proposed/main amd64 libvirt-clients amd64 6.0.0-0ubuntu8.2 [343 kB]
Get:6 http://de.archive.ubuntu.com/ubuntu focal-proposed/main amd64 libvirt0 amd64 6.0.0-0ubuntu8.2 [1.444 kB]
Get:7 http://de.archive.ubuntu.com/ubuntu focal-proposed/main amd64 libvirt-daemon amd64 6.0.0-0ubuntu8.2 [404 kB]
Fetched 2.907 kB in 2s (1.211 kB/s)
The system does not support apt-btrfs-snapshot
Preconfiguring packages ...
(Reading database ... 384131 files and directories currently installed.)
Preparing to unpack .../0-libnss-libvirt_6.0.0-0ubuntu8.2_amd64.deb ...
Unpacking libnss-libvirt:amd64 (6.0...

As I was asked to verify behavior on non-xattr systems as well I used one mounted like:
  /dev/nvme0n1p3 on /var/lib/uvtool/libvirt/images type ext4 (rw,relatime,nouser_xattr)

We see that even that isn't a showstopper as it is user_attrs and libvirtd runs as root.
# getfattr -d -m . /var/lib/uvtool/libvirt/images/focal.qcow
getfattr: Removing leading '/' from absolute path names
# file: var/lib/uvtool/libvirt/images/focal.qcow
trusted.libvirt.security.dac="+0:+100"
trusted.libvirt.security.ref_dac="1"
trusted.libvirt.security.timestamp_dac="1593600755"

I also used an ext2 which might support less attributes
  /dev/nvme0n1p3 on /var/lib/uvtool/libvirt/images type ext2 (rw,relatime,nouser_xattr)

But that still can store the xattr.

We don't build kernels without xattr to force it that way.

So finally I took a FS that can't do ownerships well in general.
/dev/nvme0n1p3 on /var/lib/uvtool/libvirt/images type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

But that isn't able to be used (permission errors) if not at the right group right away:
-rwxr-xr-x 1 root root 245104640 Jul 16 11:11 /var/lib/uvtool/libvirt/images/focal.qcow*
root@node-horsea:~# virsh start focal
error: Failed to start domain focal
error: internal error: process exited while connecting to monitor: 2020-07-16T11:48:55.976986Z qemu-system-x86_64: -blockdev {"node-name":"libvirt-2-format","read-only":false,"driver":"qcow2","file":"libvirt-2-storage","backing":"libvirt-3-format"}: Could not reopen file: Permission denied

id libvirt-qemu
uid=64055(libvirt-qemu) gid=115(kvm) groups=115(kvm),117(libvirt),64055(libvirt-qemu)

Mounted as the required user we can use it and it is not changing IDs in anyway (while running at non xattr FS)
/dev/nvme0n1p3 on /var/lib/uvtool/libvirt/images type vfat (rw,relatime,uid=64055,gid=115,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

root@node-horsea:~# ll /var/lib/uvtool/libvirt/images/focal.qcow
-rwxr-xr-x 1 libvirt-qemu kvm 245104640 Jul 16 11:11 /var/lib/uvtool/libvirt/images/focal.qcow*
root@node-horsea:~# virsh start focal
Domain focal started

root@node-horsea:~# ll /var/lib/uvtool/libvirt/images/focal.qcow
-rwxr-xr-x 1 libvirt-qemu kvm 245104640 Jul 16 11:51 /var/lib/uvtool/libvirt/images/focal.qcow*
root@node-horsea:~# virsh shutdown focal
Domain focal is being shutdown

root@node-horsea:~# ll /var/lib/uvtool/libvirt/images/focal.qcow
-rwxr-xr-x 1 libvirt-qemu kvm 246546432 Jul 16 11:52 /var/lib/uvtool/libvirt/images/focal.qcow*

I think that covers all combinations that come to mind, excluding those only available in non-Ubuntu kernels.

This bug was fixed in the package libvirt - 6.0.0-0ubuntu8.2

---------------
libvirt (6.0.0-0ubuntu8.2) focal; urgency=medium

  * enable attr support to store XATTR labels. Among other things
    this allows to properly restore file ownership (LP: #691590)
      - d/control: build depend to libattr1-dev
      - d/rules: configure --with-attr

 -- Christian Ehrhardt <email address hidden> Mon, 22 Jun 2020 21:30:50 +0200

The verification of the Stable Release Update for libvirt has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

If you come by this more than a decade later and wonder, hmm this isn't working still/again please do mind bug 2002771 that explains that this is different for "normal"-files vs read-only-files.

See https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/security_dac.c?ref_type=heads#L987
Quote:
    /* Don't restore labels on readoly/shared disks, because other VMs may
     * still be accessing these. Alternatively we could iterate over all
     * running domains and try to figure out if it is in use, but this would
     * not work for clustered filesystems, since we can't see running VMs using
     * the file on other nodes. Safest bet is thus to skip the restore step. */

Due to that it works since the fix above in >=Focal for files, but still (and never) not for .iso files which the very initial report was about.