Consider the following issue
- Using virt-manager with qemu:///session
- User adds a storage pool pointing at /tmp. No explicit permissions are
requested in the XML
- virt-manager calls PoolDefine, then PoolBuild
- libvirt tries to unconditionally chmod 755 /tmp. This fails because my
user doesn't own root. Pool build fails, virt-manager reports failure
Yes there's a couple ways we could avoid this specific case in
virt-manager, but I think it makes more sense to have pool.build on
a directory be a no-op in this case. The following patches address this.
I already pushed some bits of v2 of the series. Now the patches are:
- Patch 1 (new) update existing docs about storage <permissions>
- Patch 2 changes storage XML to not hardcode a <mode> value if the user
didn't specify one in.
- Patch 3 (new) don't output empty <permissions> block
- Patch 4 makes pool.build skip dir chmod unless the user explicitly
requested <mode> via the XML. However if a mode is required for mkdir,
continue to use the previous default.
Cole Robinson (4):
docs: formatstorage: Update <permissions> docs
storage: conf: Don't set any default <mode> in the XML
conf: storage: Don't emit empty <permissions> block
storage: fs: Only force directory permissions if required
docs/formatstorage.html.in | 40 ++++++++-----
docs/schemas/storagecommon.rng | 8 ++-
src/conf/storage_conf.c | 70 ++++++++++++----------
src/storage/storage_backend.c | 20 +++++--
src/storage/storage_backend.h | 3 +
src/storage/storage_backend_fs.c | 32 ++++++----
src/storage/storage_backend_logical.c | 4 +-
src/util/virfile.c | 4 +-
tests/storagepoolxml2xmlout/pool-netfs-gluster.xml | 3 -
tests/storagevolxml2xmlout/vol-gluster-dir.xml | 3 -
tests/storagevolxml2xmlout/vol-sheepdog.xml | 3 -
11 files changed, 113 insertions(+), 77 deletions(-)
--
2.4.1