Hide Forgot
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:
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.