Bug 677242

Summary: new volumes should inherit permissions of parent pool
Product: [Community] Virtualization Tools Reporter: Mark Wu <dwu>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: low    
Version: unspecifiedCC: crobinso, cwei, cww, dyuan, eblake, jtomko, jwest, mkarg, mschuppe, mzhan, xen-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-02-06 23:49:11 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 Mark Wu 2011-02-14 08:36:19 UTC 
Description of problem:
virt-manager doesn't honour storage pool's permission when creating a new volume 

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 6.0
libvirt-0.8.1-27.el6.x86_64
virt-manager-0.8.4-8.el6

How reproducible:
100%

Steps to Reproduce:
1. create a new storage pool in virt-manager 
2. change the permission section in xml:
# cat /etc/libvirt/storage/images-cloud.xml
<pool type='dir'>
<name>images-cloud</name>
<uuid>aebd3a39-cf7b-0c61-a814-ccc7cc69882f</uuid>
<capacity>0</capacity>
<allocation>0</allocation>
<available>0</available>
<source>
</source>
<target>
<path>/home/cloudadmin/images</path>
<permissions>
<mode>0770</mode>
<owner>500</owner> (changed default "-1" to 500. 500 is the uid for test user cloudadmin.)
<group>500</group>
</permissions>
</target>
</pool>

3. restart libvirtd
4. create a new volume in the pool via virt-manager 
  
Actual results:
The owner and group of the image file still shows as root. The mode tag also has no effect.

$ ll /home/cloudadmin/images/
total 136
-rw-------. 1 root root 1048576000 Feb  12 22:51 dfdsf.img
-rw-------. 1 root root     262144 Feb  12 21:18 fdfs.img

Expected results:
The owner, group of the image files should be cloudadmin instead of root and the permission should be 0770, instead of 0600. 


Additional info:
It works well when I use virsh to create storage pool/volume:
[root@dhcp-129-118 storage]# cat test-pool.xml 
<pool type='dir'>
  <name>test-pool</name>
  <uuid>a4e36700-90ed-f0d6-a731-722a708eece8</uuid>
  <capacity>0</capacity>
  <allocation>0</allocation>
  <available>0</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images/test-pool</path>
    <permissions>
      <mode>0700</mode>
      <owner>500</owner>
      <group>500</group>
    </permissions>
  </target>
</pool>
[root@dhcp-129-118 storage]# virsh pool-define test-pool.xml 
Pool test-pool defined from test-pool.xml

[root@dhcp-129-118 storage]# virsh pool-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes       
test-pool            inactive   no        

[root@dhcp-129-118 storage]# virsh pool-build test-pool
Pool test-pool built

[root@dhcp-129-118 storage]# ls -ldn /var/lib/libvirt/images/test-pool/
drwx------. 2 500 500 4096 Feb 14 16:05 /var/lib/libvirt/images/test-pool/

[root@dhcp-129-118 storage]# virsh pool-start test-pool
Pool test-pool started

[root@dhcp-129-118 storage]# cat test.xml 
<volume>
  <name>test.img</name>
  <key>/var/lib/libvirt/images/test-pool/test.img</key>
  <source>
  </source>
  <capacity>10485760</capacity>
  <allocation>0</allocation>
  <target>
    <path>/var/lib/libvirt/images/test-pool/test.img</path>
    <format type='raw'/>
    <permissions>
      <mode>0666</mode>
      <owner>500</owner>
      <group>500</group>
      <label>unconfined_u:object_r:virt_image_t:s0</label>
    </permissions>
  </target>
</volume>

[root@dhcp-129-118 storage]# virsh vol-create test-pool test.xml 
Vol test.img created from test.xml
[root@dhcp-129-118 storage]# ls -ln /var/lib/libvirt/images/test-pool/test.img 
-rw-rw-rw-. 1 500 500 10485760 Feb 14 16:08 /var/lib/libvirt/images/test-pool/test.img
Comment 1 Chris Williams 2011-02-24 18:28:58 UTC 
This bug was not resolved before development freeze.  We are now making preparations for the launch of 6.1 and are only accepting critical and high impact bugs.  We're reflagging this bug for 6.2 to continue the review and work needed to resolve this bug.
Comment 2 Cole Robinson 2011-04-07 16:28:10 UTC 
Pretty sure this is a libvirt issue, since virt-manager/virtinst don't specify permissions by default. Libvirt should make sure new volumes inheirit permissions of parent pool
Comment 5 Nan Zhang 2011-11-23 06:59:32 UTC 
Now I can reproduce this bug with libvirt-0.9.4-23.el6.x86_64 & virt-manager-0.9.0-7.el6.x86_64.
Comment 9 Cole Robinson 2019-02-06 23:49:11 UTC 
Julio attempted a patch here: https://www.redhat.com/archives/libvir-list/2019-January/msg00669.html

But I don't think we will change this unconditionally... the behavior has been like this for a decade and not generated many complaints. John had some ideas in the thread about possibly adding new features, but those should be separate issues/discussions