libvirt restore exactly the old ownership of images
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libvirt (Ubuntu) |
Fix Released
|
Medium
|
Christian Ehrhardt | ||
Focal |
Fix Released
|
Medium
|
Unassigned |
Bug Description
[Impact]
* A rather old bug which could have been solved much sooner. Attr support
was disabled way back in time for triggering some test issues. Since
then the test issues and also many more rough edges of ATTR support have
been fixed.
* This change shall enable attr support again which allows libvirt to
remember and carry ownership information on image files as extended
attributes.
[Test Case]
* Prepare a guest that you can start/stop e.g. with uvtool-libvirt
* Own the image by anything other than root:root
* Start the guest (ownership will change to the user the guest runs as)
* Stop the guest:
- fail: will set root:root to the images effectively stealing them
- correct: remembers the old ownership and restores that
[Regression Potential]
* This mostly influences DAC control of files, which is exactly what we
want to fix. There are a few lifecycle tasks which now also have to
carry labels e.g. on any image handling. I don't expect regressions, but
this is the place to look out for.
* The behavior on File systems unable to XATTR matches that of the
formerly disable feature, so on those cases where it has no positive
change it will have no change at all.
[Other Info]
* Technically we could backport this into all releases, but while I find
it right to fix in Focal OTOH Bionic and even more so Xenial really are
even "more stable" after their time in the field. Users either have
adapted already or even rely/expect the semi-broken behavior. Therefore
this is only targetting Focal intentionally.
* (very) worst case one can set the FS the images are on to "nouser_xattr"
as mount option.
---
Natty (and it was also the same on Maverick, IIRC).
When you assign an ISO to a VM, libvirt will take over onwership of the ISO. This creates problems if the ISO is updated.
For example, I am daily updating the Natty server ISOs, and running tests on them via KVM (all automated). The ISO updates will fail because libvirt chowns them.
I see no reason for this: libvirt only needs the ISO as input.
WORKAROUND:
edit /etc/libvirt/
Related branches
- Andreas Hasenack: Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 58 lines (+13/-1)3 files modifieddebian/changelog (+9/-0)
debian/control (+1/-0)
debian/rules (+3/-1)
- Rafael David Tinoco (community): Approve
- Canonical Server: Pending requested
- Canonical Server packageset reviewers: Pending requested
-
Diff: 58 lines (+13/-1)3 files modifieddebian/changelog (+9/-0)
debian/control (+1/-0)
debian/rules (+3/-1)
tags: | added: natty qa |
tags: | added: iso-testing |
Changed in libvirt (Ubuntu): | |
status: | Triaged → Won't Fix |
description: | updated |
description: | updated |
Changed in libvirt: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
affects: | libvirt → libvirt (Baltix) |
affects: | libvirt (Baltix) → ubuntu-translations |
no longer affects: | ubuntu-translations |
description: | updated |
Changed in libvirt (Ubuntu Focal): | |
importance: | Undecided → Medium |
status: | New → Triaged |
Description of problem:
When I use an install ISO image labeled public_content_t, virt-manager will relabel it as virt_content_t without any warnings. It will also change its owner and group to qemu. It should allow virtual machines to read those files (which might also be shared via http, samba or nfs).
Version-Release number of selected component (if applicable): 0.8.2-1. fc12.noarch. rpm
virt-manager-
How reproducible:
Every time.
Steps to Reproduce:
1. Create a new VM.
2. Select an ISO image labeled public_content_t.
3. Continue all the steps until the machine is started.
Actual results:
The ISO image will be labeled virt_content_t and its owner and group will be changed to qemu.
Expected results:
A warning should be displayed if the permissions of the file need to be changed or even better allow the virtual machine to read public_content_t files.
Additional info: 0.7.1-15. fc12.x86_ 64.rpm policy- targeted- 3.6.32- 89.fc12. noarch. rpm
I'm also using the following packages:
libvirt-
selinux-
A related RFE is bug #568933.