Bug 796072 - libvirt do not change back image's ownership after destroy the guest when dynamic_ownership = 1
Summary: libvirt do not change back image's ownership after destroy the guest when dyn...
Keywords:
Status: CLOSED DUPLICATE of bug 547546
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: x86_64
OS: Linux
low
low
Target Milestone: rc
: ---
Assignee: Laine Stump
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-22 08:39 UTC by Huang Wenlong
Modified: 2013-10-20 21:45 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-10-02 09:52:51 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Huang Wenlong 2012-02-22 08:39:34 UTC
Description of problem:
libvirt do not change back image's ownership after destroy the guest when dynamic_ownership = 1
the test environment is local not NFS and the filesystem is ext4 .


Version-Release number of selected component (if applicable):
libvirt-0.9.10-2.el6.x86_64

How reproducible:
100%

Steps to Reproduce:

make sure  dynamic_ownership is defualt(1)
cat /etc/libvirt/qemu.conf |grep owner
# Whether libvirt should dynamically change file ownership
# Set to 0 to disable file ownership changes.
#dynamic_ownership = 1



1. create a image in /var/lib/libvirt/images
# qemu-img create /var/lib/libvirt/images/test2.img  1G

2. change owner to qemu:qemu
#chown qemu:qemu  /var/lib/libvirt/images/test2.img

3. create a guest with test2.img
...
<disk type='file' device='disk'>
<driver name='qemu' type='raw' cache='none'/>
<source file='/var/lib/libvirt/images/test2.img'/>
<target dev='hda' bus='ide'/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' unit='0'/>
</disk>

...


4. start the guest  then check the image
#ll  /var/lib/libvirt/images/test2.img
-rw-r--r--.  1 qemu   qemu   1073741824 Feb 22 14:32 test2.img



5. destroy the guest then check the image
# ll /var/lib/libvirt/images/test2.img
-rw-r--r--. 1 root root 1073741824 Feb 22 14:32 /tmp/test2.img



Actual results:
ownership do not change back

Expected results:
ownership should change back

Additional info:
virsh save have a same problem like this , a exist qeme:qemu File , after save a guest to it ,and restore , it ownership will be root:root

Comment 2 Jiri Denemark 2012-02-22 09:24:22 UTC
I think it works as expected. Dynamic ownership expects each file to be owned by root:root. When a domain is started, all required files are chowned to the qemu user and once the domain goes down, files are returned back to root:root.

Comment 3 Huang Wenlong 2012-02-22 09:43:12 UTC
(In reply to comment #2)
> I think it works as expected. Dynamic ownership expects each file to be owned
> by root:root. When a domain is started, all required files are chowned to the
> qemu user and once the domain goes down, files are returned back to root:root.

If the original image's ownership is not root,  libvirt should not force to change it from others to root after libvirt used it , I think it will be better to  change the ownership to original after guest down and keep the file consistent 

Wenlong

Comment 4 Jiri Denemark 2012-02-22 10:10:40 UTC
Yeah, I agree this would be a useful thing to do, although it's hard (maybe even impossible) to do reliably.

Comment 5 Laine Stump 2012-02-22 17:25:24 UTC
There are many existing/closed bug reports related to this issue. The current situation is that if the file is on a read-only root-squash filesystem (i.e. somewhere that libvirt doesn't have the necessary permission to chown it), the operation will still succeed, and the file's ownership will not change (See 702044 for example).

Restoring the original ownership of a file (rather than hard-coding to root:root, as is done currently) will require a re-working of libvirt's DAC security driver, which is not a short-term possibility. I had thought that we had an open BZ to track this, but can't find one right now, so I'm leaving this bug open in the meantime.

Comment 7 dyuan 2012-02-23 02:36:24 UTC
(In reply to comment #5)
> There are many existing/closed bug reports related to this issue. The current
> situation is that if the file is on a read-only root-squash filesystem (i.e.
> somewhere that libvirt doesn't have the necessary permission to chown it), the
> operation will still succeed, and the file's ownership will not change (See
> 702044 for example).
> 
> Restoring the original ownership of a file (rather than hard-coding to
> root:root, as is done currently) will require a re-working of libvirt's DAC
> security driver, which is not a short-term possibility. I had thought that we
> had an open BZ to track this, but can't find one right now, so I'm leaving this
> bug open in the meantime.

The existing bug 547546, and it's from the discussion in bug 534010.

Just for a record, bug 716478 and bug 661720 are related to dynamic_ownership=0.

Comment 9 Jiri Denemark 2012-10-02 09:52:51 UTC
Right, the existing bug is 547546. I'm closing this one as a duplicate of it.

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


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