https://bugzilla.redhat.com/show_bug.cgi?id=1282288
Although commit id '77346f27' resolves part of the problem regarding creating
a qemu-img image in an NFS root-squash environment, it really didn't fix the
entire problem. Unfortunately it only masked the problem. It seems qemu-img
must open/create the image using 0644, which if used by target.perms would
result in the chmod not being called since the mode desired and set match.
Although qemu-img could conceivably ignore the mode when creating, libvirt
has more knowledge of the environment and can make the adjustment to the
mode far more easily by using virFileOpenAs with VIR_FILE_OPEN_FORCE_MODE.
If that's successful, then we know on return the file will have the right
owner and mode, so we can declare success
Signed-off-by: John Ferlan <jferlan(a)redhat.com>
---
src/storage/storage_backend.c | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c
index 77e87b3..3f36aa3 100644
--- a/src/storage/storage_backend.c
+++ b/src/storage/storage_backend.c
@@ -702,8 +702,28 @@ virStorageBackendCreateExecCommand(virStoragePoolObjPtr pool,
if (virCommandRun(cmd, NULL) == 0) {
/* command was successfully run, check if the file was created */
- if (stat(vol->target.path, &st) >= 0)
+ if (stat(vol->target.path, &st) >= 0) {
filecreated = true;
+
+ /* seems qemu-img disregards umask and open/creates using 0644.
+ * If that doesn't match what we expect, then let's try to
+ * re-open the file and attempt to force the mode change.
+ */
+ if (mode != (st.st_mode & S_IRWXUGO)) {
+ int fd = -1;
+ int flags = VIR_FILE_OPEN_FORK | VIR_FILE_OPEN_FORCE_MODE;
+
+ if ((fd = virFileOpenAs(vol->target.path, O_RDWR, mode,
+ vol->target.perms->uid,
+ vol->target.perms->gid,
+ flags)) >= 0) {
+ /* Success - means we're good */
+ VIR_FORCE_CLOSE(fd);
+ ret = 0;
+ goto cleanup;
+ }
+ }
+ }
}
}
--
2.5.0