On 02/13/2017 09:18 PM, Andrea Bolognani wrote:
When we populate the private /dev that's going to be used by an isolated QEMU process, we take care all metadata matches what's in the top-level namespace: in particular, we copy the file permissions directly.
However, since the permissions passed to mknod() are still affected by the active umask, we need to set it to a very permissive value before creating device nodes to avoid file access issues.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1421036 --- src/qemu/qemu_domain.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c index f62bf8f..7993acc 100644 --- a/src/qemu/qemu_domain.c +++ b/src/qemu/qemu_domain.c @@ -7040,6 +7040,7 @@ qemuDomainCreateDeviceRecursive(const char *device, #ifdef WITH_SELINUX char *tcon = NULL; #endif + mode_t oldUmask = umask((mode_t) 0);
if (!ttl) { virReportSystemError(ELOOP, @@ -7205,6 +7206,7 @@ qemuDomainCreateDeviceRecursive(const char *device, #ifdef WITH_SELINUX freecon(tcon); #endif + umask(oldUmask); return ret; }
There are couple of returns in between these two chunks so new umask will be leaked. Moreover, the current umask at this point should be 002 as a result of virCommandSetUmask() called from qemuProcessLaunch(). virCommandRun() then sets the umask also for the pre-exec hook. Does it make sense to run the pre-exec hook with unchanged umask? But as we are discussing in person right now, there is something fishy going on: on ppc and aarch64 the umask is honoured when calling mknod() but on x86_64 it is not. Maybe somebody on the list has a bright idea why that might be? Michal