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
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.
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
Now I can reproduce this bug with libvirt-0.9.4-23.el6.x86_64 & virt-manager-0.9.0-7.el6.x86_64.
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