Bug 1415940 - the dir's permission is changed after creating a dir pool
Summary: the dir's permission is changed after creating a dir pool
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.9
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Libvirt Maintainers
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-24 07:09 UTC by Xiaodai Wang
Modified: 2017-03-02 19:32 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-02 19:32:35 UTC
Target Upstream Version:


Attachments (Terms of Use)

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):
virt-manager-0.9.0-34.el6.x86_64
libvirt-0.10.2-62.el6.x86_64

How reproducible:
100%

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
    can't.
    
    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
    it.


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