Bug 796072

Summary:	libvirt do not change back image's ownership after destroy the guest when dynamic_ownership = 1
Product:	Red Hat Enterprise Linux 7	Reporter:	Huang Wenlong <whuang>
Component:	libvirt	Assignee:	Laine Stump <laine>
Status:	CLOSED DUPLICATE	QA Contact:
Severity:	low	Docs Contact:
Priority:	low
Version:	7.0	CC:	acathrow, cwei, dallan, dyuan, gsun, jdenemar, mzhan, rwu
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-10-02 09:52:51 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 ***