Bug 677242 - new volumes should inherit permissions of parent pool
Summary: new volumes should inherit permissions of parent pool
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-02-14 08:36 UTC by Mark Wu
Modified: 2022-03-13 13:50 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-06 23:49:11 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 43349 0 None None None Never

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


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