Bug 1480382

## Description of problem:

With the correct polkit rule, a user can manage the system mode daemon with qemu:///system.

In such configuration, virt-install fails to complete because the qemu process cannot access the kernel image.

----
Aug 11 00:01:14 kvm13.lab.local libvirtd[27929]: 2017-08-10 22:01:14.583+0000: 27931: error : qemuProcessReportLogError:1862 : internal error: process exited while connecting to monitor: qemu: could not load kernel '/var/lib/libvirt/boot/virtinst-vmlinuz.ruXFEj': Permission denied
----

When using the qemu:///system URI, virt-install saves the kernel into the system scratchdir /var/lib/libvirt/boot/ :

----
[Fri, 11 Aug 2017 00:01:13 virt-install 3287] DEBUG (urlfetcher:90) Fetching URI: http://host.lab.local/pub/rhel/7.3/os/x86_64/images/pxeboot/vmlinuz
Retrieving file vmlinuz...                                                                  | 5.1 MB  00:00:00
[Fri, 11 Aug 2017 00:01:13 virt-install 3287] DEBUG (urlfetcher:166) Saved file to /var/lib/libvirt/boot/virtinst-vmlinuz.ruXFEj
----

If the user for QEMU processes run by the system instances is not the current user, nor root, the installation fails because this user cannot read the kernel file. The file owner is the user who executes the virt-install command:

----
# ls -l /var/lib/libvirt/boot/
total 48924
-rw------- 1 bruno support 44701632 Aug 11 00:01 virtinst-initrd.img.1FF624
-rw------- 1 bruno support  5391264 Aug 11 00:01 virtinst-vmlinuz.ruXFEj
----

The mode is set to 0600 by tempfile.NamedTemporaryFile(), thus the qemu process cannot read the files.

## Version-Release number of selected component (if applicable):

virt-manager-common-1.4.1-7.el7.noarch
libvirt-3.2.0-14.el7_4.2.x86_64

$ cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 7.4 (Maipo)

## How reproducible:

Easily

## Steps to Reproduce:
1. Configure polkit

# cat /etc/polkit-1/rules.d/48-org.libvirt.unix.manager.rules
/* Allow users in support group to manage the libvirt
daemon without authentication */
polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.manage" &&
        subject.isInGroup("support")) {
            return polkit.Result.YES;
    }
});

2. If needed, change the group and mode of /var/lib/libvirt/images and /var/lib/libvirt/boot

# chgrp support /var/lib/libvirt/{boot,images}
# chmod 731 /var/lib/libvirt/{boot,images}

3. As a user, start virt-install (must be member of group support)

$ id
uid=1182(bruno) gid=1000(support) groups=1000(support)
$ /usr/bin/python2 /usr/share/virt-manager/virt-install --connect qemu:///system --name demo2 --ram 4096 --vcpus 2 --virt-type kvm --machine pc --location http://host.lab.local/pub/rhel/7.3/os/x86_64/  --arch x86_64 --os-variant rhel7.0 --disk path=/var/lib/libvirt/images/demo2-disk0,size=10,format=qcow2 --wait 0 --debug
 

## Actual results:

The installation of the virtual guest fails.


## Expected results:

The installation of the virtual guest completes.

## Additional info:

I have been able to workaround this issue with the following patch in urlfetcher:

----
diff -u /usr/share/virt-manager/virtinst/urlfetcher.py.ori /usr/share/virt-manager/virtinst/urlfetcher.py
--- /usr/share/virt-manager/virtinst/urlfetcher.py.ori  2017-03-08 22:55:43.000000000 +0100
+++ /usr/share/virt-manager/virtinst/urlfetcher.py      2017-08-11 00:21:21.705304598 +0200
@@ -160,6 +160,7 @@
             fileobj = tempfile.NamedTemporaryFile(
                 dir=self.scratchdir, prefix=prefix, delete=False)
             fn = fileobj.name
+            os.chmod(fn, 0640)
 
         self._grabURL(filename, fileobj)
         logging.debug("Saved file to " + fn)
----