Bug 1415940

Summary: the dir's permission is changed after creating a dir pool
Product: Red Hat Enterprise Linux 6 Reporter: Xiaodai Wang <xiaodwan>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.9CC: crobinso, juzhou, kuwei, mxie, mzhan, phrdina, rbalakri, tzheng
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-03-02 19:32:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Xiaodai Wang 2017-01-24 07:09:51 UTC
Description of problem:
the dir's permission is changed after creating a dir pool

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Prepare a dir and change it's permission to "777"
   drwxrwxrwx. 2 root root        4096 Jan 24 14:33 haha
2. Create a dir pool and choose the above dir as pool directory.
3. Check the permission of the dir.

Actual results:
The permission of the dir is changed to "755".
drwxr-xr-x. 2 root root        4096 Jan 24 14:33 haha

And if setting '/tmp' as a pool directory, after rebooting host,
Error "There is a problem with the configuration server.
(/usr/libexec/gconf-sanity-check-2 exited with status 256)" will pop up and users cannot login to desktop.

Expected results:
The dir's permission should keep same.

Additional info:

Comment 2 Cole Robinson 2017-03-02 19:32:35 UTC
This is actually more an issue with libvirt, that was fixed upstream a while back. Basically libvirt would force 755 perms unless we specified them in the XML. It should not alter perms for an existing dir unless a change is requested in the XML.

So moving to libvirt, but closing as WONTFIX for RHEL6 given that we've come this far with that behavior and there isn't a customer complaint

commit db1140f117cf313a75711f277df51e9ce80717ed
Author: Cole Robinson <crobinso@redhat.com>
Date:   Mon Apr 27 16:48:05 2015 -0400

    storage: fs: Only force directory permissions if required
    Only set directory permissions at pool build time, if:
    - User explicitly requested a mode via the XML
    - The directory needs to be created
    - We need to do the crazy NFS root-squash workaround
    This allows qemu:///session to call build on an existing directory
    like /tmp.

commit 7c2d65dde2595c07d56aad1e043f7b1836592d89
Author: Cole Robinson <crobinso@redhat.com>
Date:   Mon Apr 27 16:48:05 2015 -0400

    storage: conf: Don't set any default <mode> in the XML
    The XML parser sets a default <mode> if none is explicitly passed in.
    This is then used at pool/vol creation time, and unconditionally reported
    in the XML.
    The problem with this approach is that it's impossible for other code
    to determine if the user explicitly requested a storage mode. There
    are some cases where we want to make this distinction, but we currently
    Handle <mode> parsing like we handle <owner>/<group>: if no value is
    passed in, set it to -1, and adjust the internal consumers to handle