Bug 547546 - RFE: the security drivers must remember original permissions/labels and restore them after
Summary: RFE: the security drivers must remember original permissions/labels and resto...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: yafu
: 796072 1113327 1126678 1191802 (view as bug list)
Depends On: 1524792
Blocks: 1203710 1205796 1420851 1477664 756082 822052 829181 1126678 1288337
TreeView+ depends on / blocked
Reported: 2009-12-14 21:58 UTC by Daniel Berrangé
Modified: 2019-08-08 02:46 UTC (History)
27 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1652078 (view as bug list)
Last Closed: 2019-04-17 12:38:02 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 636156 0 low CLOSED RFE: security: restore original file label/owner 2021-02-22 00:41:40 UTC

Internal Links: 636156

Description Daniel Berrangé 2009-12-14 21:58:04 UTC
Description of problem:
The current SELinux and uid/gid changing code always restores the permissions back to a default generic label, and root:root respectively. These are bad assumptions, because the original file may have had non-default/non-root labelling/ownership.

There needs to be a mechanism for the security drivers to record the original credentials, so they can be correctly restored later. This needs to be persistent across libvirtd restart, and cope with multiple guests using the same files concurrently.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 2 RHEL Program Management 2009-12-14 22:26:04 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for

Comment 3 Daniel Berrangé 2010-01-20 15:47:58 UTC

*** This bug has been marked as a duplicate of bug 534010 ***

Comment 4 Laine Stump 2011-08-24 19:50:34 UTC
Bug 534010 was initially opened for a much narrower problem (image files are chowned to root during domain restore, even if dynamic_ownership=0), which has been resolved. In order to track the larger problem properly, I'm re-opening this bug rather than creating a new one.

Comment 6 Wayne Sun 2011-11-29 07:43:51 UTC
# rpm -q libvirt

possible test steps:

scenario 1:
1. prepare a domain, chown the disk file to non-root user
# chown wayne:wayne /var/lib/libvirt/images/rhel6u2
# ll -Z /var/lib/libvirt/images/
-rw-r--r--. wayne wayne system_u:object_r:virt_image_t:s0 rhel6u2

2. start the domain
# virsh start rhel6u2
Domain rhel6u2 started

3. check the file ownership
# ll -Z /var/lib/libvirt/images/rhel6u2
-rw-r--r--. qemu qemu system_u:object_r:svirt_image_t:s0:c31,c303 /var/lib/libvirt/images/rhel6u2

4. destroy the domain and recheck
# virsh destroy rhel6u2
Domain rhel6u2 destroyed

# ll -Z /var/lib/libvirt/images/rhel6u2
-rw-r--r--. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/rhel6u2

5. restart libvirtd and recheck
# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]
# ll -Z /var/lib/libvirt/images/rhel6u2
-rw-r--r--. root root system_u:object_r:virt_image_t:s0 /var/lib/libvirt/images/rhel6u2

^^after destroy and libvirtd restart, the disk file restore to root:root

scenario 2:
1. prepare a shareable non-root iso file
# ll -Z /var/lib/libvirt/images/aa.iso
-rw-r--r--. wayne wayne system_u:object_r:virt_content_t:s0 aa.iso

2. attach the iso file to active domain and check ownership
prepare insert.xml using /var/lib/libvirt/images/aa.iso as source file
# virsh update-device rhel6u2 insert.xml
Device updated successfully

# ll -Z /var/lib/libvirt/images/aa.iso 
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/aa.iso

3. eject the iso file and recheck
# virsh update-device rhel6u2 /root/eject.xml 
Device updated successfully

# ll -Z /var/lib/libvirt/images/aa.iso 
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/aa.iso

4. destroy domain and recheck
# virsh destroy rhel6u2
Domain rhel6u2 destroyed

# ll -Z /var/lib/libvirt/images/aa.iso 
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/aa.iso

5. restart libvirtd and recheck
# service libvirtd restart
Stopping libvirtd daemon:                                  [  OK  ]
Starting libvirtd daemon:                                  [  OK  ]
# ll -Z /var/lib/libvirt/images/aa.iso 
-rw-r--r--. qemu qemu system_u:object_r:virt_content_t:s0 /var/lib/libvirt/images/aa.iso

^^after detach and restart libvirtd, the shareable iso file remain qemu:qemu

Comment 7 Martin Kletzander 2012-05-25 13:38:02 UTC
As you mentioned in Bug 534010, there are three possibilities to go around this problem. The cleaner ones (xattr or acl) are not possible on all mounts/filesystems.
My question is if we can say that dynamic_ownership=1 is only supported on these mounts and otherwise behave the same way as with dynamic_ownership=0, but with warning (for example)?

Comment 8 Martin Kletzander 2012-05-30 16:13:09 UTC
Setting CondNAK:Design as we're not sure which way to head with this problem yet.

Comment 9 Jiri Denemark 2012-10-02 09:52:51 UTC
*** Bug 796072 has been marked as a duplicate of this bug. ***

Comment 11 Richard W.M. Jones 2013-05-31 08:18:00 UTC
Make bug non-private.

Comment 12 Daniel Berrangé 2013-12-13 12:38:34 UTC
Clearing needinfo flag, since this discussion moved upstream.

Comment 15 Jiri Denemark 2014-08-05 14:06:33 UTC
*** Bug 1113327 has been marked as a duplicate of this bug. ***

Comment 16 Michal Privoznik 2014-09-10 13:27:45 UTC
I've proposed patches upstream:


Comment 18 Michal Privoznik 2014-12-01 10:03:11 UTC
*** Bug 1126678 has been marked as a duplicate of this bug. ***

Comment 22 Ján Tomko 2016-02-11 09:28:45 UTC
*** Bug 1191802 has been marked as a duplicate of this bug. ***

Comment 30 Adrien 2018-07-10 07:59:39 UTC
Hi all,

I've just hit this problem of restoring permissions to root:root when undefining a domain.
I'm surprised to see that this issue was opened on 2009 and still opened :-/
Is their anything to do to find a solution?


Comment 33 Michal Privoznik 2018-07-27 12:37:21 UTC
I've started some discussion upstream:


Comment 37 Michal Privoznik 2018-12-19 15:29:11 UTC
And I've just pushed patches to the master:

e05d8e570b qemu.conf: Allow users to enable/disable label remembering
1845991d9b tools: Provide a script to recover fubar'ed XATTRs setup
1e63dea999 tests: Introduce qemusecuritytest
d9043c06e6 virSecuritySELinuxRestoreAllLabel: Restore more labels
d81f3e02d7 virSecuritySELinuxRestoreAllLabel: Reorder device relabeling
edacf25da7 virSecuritySELinuxTransactionRun: Implement rollback
b44fd42016 security_selinux: Restore label on failed setfilecon() attempt
4dc37a39cf security_selinux: Remember old labels
1e9c472452 security_selinux: Track if transaction is restore
d7420430ce virSecurityDACRestoreImageLabelInt: Restore even shared/RO disks
1845d3ad5d security_dac: Remember old labels
fa808763b2 security_dac: Allow callers to enable/disable label remembering/recall
a30e6d17c9 virSecurityDACRestoreAllLabel: Restore more labels
08e3b1c0dc virSecurityDACRestoreAllLabel: Reorder device relabeling
06af6609e9 virSecurityDACTransactionRun: Implement rollback
86def3c88c security_dac: Restore label on failed chown() attempt
f9a0019fea security: Include security_util
f497b1ad59 util: Introduce xattr getter/setter/remover


Comment 38 Jiri Denemark 2019-01-25 11:29:57 UTC
This feature was disabled upstream due to some non-trivial bugs by

commit fc3990c7e64be1da1631952d3ec384ebef50e125
Refs: v5.0.0-rc2-4-gfc3990c7e6
Author:     Michal Privoznik <mprivozn@redhat.com>
AuthorDate: Mon Jan 14 17:53:43 2019 +0100
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: Tue Jan 15 09:45:22 2019 +0100

    qemu: Temporary disable owner remembering

    Turns out, that there are few bugs that are not that trivial to
    fix (e.g. around block jobs). Instead of rushing in not
    thoroughly tested fixes disable the feature temporarily for the

    Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
    ACKed-by: Peter Krempa <pkrempa@redhat.com>

Comment 39 Michal Privoznik 2019-03-28 15:26:18 UTC
Patches for the bugs posted upstream:


Comment 40 Jaroslav Suchanek 2019-04-17 12:38:02 UTC
This will be fixed in rhel-8 version in the bug 1652078.

Note You need to log in before you can comment on or make changes to this bug.