815644 – There is no executable permission on default pool.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 815644 - There is no executable permission on default pool.

Summary: There is no executable permission on default pool.

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	libvirt
Sub Component:
Version:	6.3
Hardware:	x86_64
OS:	Linux
Priority:	low
Severity:	low
Target Milestone:	rc
Target Release:	---
Assignee:	Osier Yang
QA Contact:	Virtualization Bugs
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+	depends on / blocked

Reported:	2012-04-24 07:06 UTC by lei wang
Modified:	2013-02-21 07:12 UTC (History)
CC List:	11 users (show)
Fixed In Version:	libvirt-0.10.0-0rc0.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2013-02-21 07:12:01 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2013:0276	0	normal	SHIPPED_LIVE	Moderate: libvirt security, bug fix, and enhancement update	2013-02-20 21:18:26 UTC

Description lei wang 2012-04-24 07:06:04 UTC

Description of problem:
There is no executable permission on default pool.

Version-Release number of selected component (if applicable):
# rpm -qa |grep libvirt
libvirt-python-0.9.10-11.el6.x86_64
libvirt-debuginfo-0.9.10-11.el6.x86_64
libvirt-client-0.9.10-11.el6.x86_64
libvirt-0.9.10-11.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.# virsh pool-dumpxml default
<pool type='dir'>
  <name>default</name>
  <uuid>7d7ac6da-3fc8-f835-edc1-87f65df39e93</uuid>
  <capacity unit='bytes'>42275766272</capacity>
  <allocation unit='bytes'>7853170688</allocation>
  <available unit='bytes'>34422595584</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

  
Actual results:
No executable permission on it.

Expected results:
There is executable permission on mode tag.

Additional info:

Comment 2 Jiri Denemark 2012-04-24 10:22:03 UTC

I don't see any issue in your bug description. The mode element says 700, where 7 is 4 + 2 + 1, i.e., all r, w, and x bits are set.

Comment 3 Huang Wenlong 2012-04-24 10:30:13 UTC

1) I found "default" pool 's  permission is 0711 actually , but pool-dumpxml is  0700
 #ll  /var/lib/libvirt/images/ -d
drwx--x--x. 8 root root 4096 Apr 19 11:03 /var/lib/libvirt/images/

# virsh pool-dumpxml default
<pool type='dir'>
  <name>default</name>
  <uuid>736c6f23-2afe-0f4f-294b-3d8864f5872f</uuid>
  <capacity unit='bytes'>30963351552</capacity>
  <allocation unit='bytes'>20410916864</allocation>
  <available unit='bytes'>10552434688</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images</path>
    <permissions>
      <mode>0700</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

2) if the folder permission is real "0700" then libvirt can not start guest  which its image is in that folder, because  qemu has not execute permission for the folder .
Now If you create a new dir pool with virt-manager ,the dir is real 0700 but virt-manager will help you to fix it by setfacl , add qemu "x" permission ,when try to start a guest .

Comment 5 Osier Yang 2012-07-11 14:42:41 UTC

Commit in upstream: 8a544719aa

Comment 7 zhe peng 2012-08-06 05:28:31 UTC

test with  libvirt-0.10.0-0rc0.el6.x86_64
  below is my step
step:
   1:remove all libvirt package,& #rm /var/lib/libvirt -rf
   2:install libvirt latest pkg and start libvirtd
    #rpm -ivh libvirt*
    #service libvirtd start
   3:check default pool
    #virsh pool-dumpxml default
......
   <target>
    <path>/var/lib/libvirt/images</path>
    <permissions>
      <mode>0700</mode>
      <owner>4294967295</owner>
      <group>4294967295</group>
    </permissions>
  </target>
......
    #ls -dl /var/lib/libvirt/images
   drwx--x--x. 2 root root 4096 Aug  2 03:46 /var/lib/libvirt/images/
   the dir permission is 711

the mode not 755 , always 700 in dumpxml ,hi osier, is it right?
but when i create a new pool, the permissions mode is 755.

Comment 8 zhe peng 2012-11-15 07:27:32 UTC

verify with libvirt-0.10.2-8.el6.x86_64

step:
  1: create a new env. for libvirt
  2: cat pool.xml
  <pool type='dir'>
  <name>default</name>
    <uuid>736c6f23-2afe-0f4f-294b-3d8864f5872f</uuid>
      <capacity unit='bytes'>30963351552</capacity>
        <allocation unit='bytes'>20410916864</allocation>
          <available unit='bytes'>10552434688</available>
            <source>
              </source>
                <target>
                    <path>/var/lib/libvirt/images</path>
                        <permissions>
                            <owner>-1</owner>
                             <group>-1</group>
                        </permissions>
                 </target>
           </pool>
   3: define and start pool
    #virsh pool-define pool.xml
    #virhs pool-start default
   4: check pool permissions
    #virsh pool-dumpxml default
       <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
   #ls -al /var/lib/libvirt
   drwxr-xr-x. 19 root root 81920 Nov 15 02:05 images

verification passed.

Comment 9 Luwen Su 2013-01-15 03:58:04 UTC

Hi osier ,
In libvirt-0.10.2-15 , after reinstall libvirt , the default pool's permission doesn't match from the xml to the folder , should we reopen this bug?

In RHEL6.4 snap3
#rm -rf /var/lib/libvirt
#yum remove libvirt
#yum install libvirt

#rpm -q libvirt
libvirt-0.10.2-15.el6.x86_64
#service libvirtd start
Starting libvirtd daemon:                                  [  OK  ]

# virsh pool-list --all
Name                 State      Autostart 
-----------------------------------------
default              active     yes       

# ll -d /var/lib/libvirt/images/
drwx--x--x. 2 root root 4096 Jan  9 22:51 /var/lib/libvirt/images/

# virsh pool-dumpxml default
<pool type='dir'>
  <name>default</name>
  <uuid>5fd3f4bb-8c3f-0738-9ecf-b362b2c0258f</uuid>
  <capacity unit='bytes'>42275766272</capacity>
  <allocation unit='bytes'>2305581056</allocation>
  <available unit='bytes'>39970185216</available>
  <source>
  </source>
  <target>
    <path>/var/lib/libvirt/images</path>
    <permissions>
      <mode>0755</mode>
      <owner>-1</owner>
      <group>-1</group>
    </permissions>
  </target>
</pool>

Comment 10 Luwen Su 2013-01-17 05:55:36 UTC

(In reply to comment #9)
After refresh , still keep 711 ,test in libvirt -16

# ll /var/lib/libvirt/images/ -d
drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/

# virsh pool-refresh default
Pool default refreshed

ll /var/lib/libvirt/images/ -d
drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/

Comment 11 Osier Yang 2013-01-17 10:28:47 UTC

(In reply to comment #10)
> (In reply to comment #9)
> After refresh , still keep 711 ,test in libvirt -16
> 
> # ll /var/lib/libvirt/images/ -d
> drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/
> 
> # virsh pool-refresh default
> Pool default refreshed
> 
> ll /var/lib/libvirt/images/ -d
> drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/

If you have started the pool after the re-installing, the directory permission
modes are expected to be updated with 0755. It's bug if it's not updated. But
please open a new bug instead, this bug is only for changing the default pool
permission.

And to reproduce it, you don't have to reinstall the libvirt. Do like
following should work:

1) Create a directory like "/var/lib/libvirt/pool-test" with permission like
   0711
2) define a pool with target permissions modes like 0755 (different with what
   you used to create the directory in 1))
3) start the pool
4) Check if the directory's permission is updated to 0755.

Comment 12 Osier Yang 2013-01-17 10:32:39 UTC

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)
> > After refresh , still keep 711 ,test in libvirt -16
> > 
> > # ll /var/lib/libvirt/images/ -d
> > drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/
> > 
> > # virsh pool-refresh default
> > Pool default refreshed
> > 
> > ll /var/lib/libvirt/images/ -d
> > drwx--x--x. 2 root root 4096 Jan 16 23:31 /var/lib/libvirt/images/
> 
> If you have started the pool after the re-installing, the directory
> permission
> modes are expected to be updated with 0755. It's bug if it's not updated. But
> please open a new bug instead, this bug is only for changing the default pool
> permission.
> 
> And to reproduce it, you don't have to reinstall the libvirt. Do like
> following should work:
> 
> 1) Create a directory like "/var/lib/libvirt/pool-test" with permission like
>    0711
> 2) define a pool with target permissions modes like 0755 (different with what
>    you used to create the directory in 1))
> 3) start the pool

s/start/pool-build/

> 4) Check if the directory's permission is updated to 0755.

Comment 13 Luwen Su 2013-02-06 06:18:01 UTC

I test per comment 11 , get the expected reslut.

Comment 14 errata-xmlrpc 2013-02-21 07:12:01 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0276.html

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