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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
