Package: virtinst
Version: 0.500.6-1

If the umask is set to 007, virt-install will fail with an error like
this:

  qemu: could not load kernel
  '/home/rlb/.virtinst/boot/virtinst-linux.sQocL_': Permission denied

Ideally, virt-install shouldn't be affected by the user's umask, and
shouldn't require a world-accessible $HOME.

If the relevant files are just temporary files that are used during the
install, then I'd suggest that they be written with umask 002 to a
securely created temp dir, i.e. via "mktemp --tmpdir -d", or in python:

  tempfile.mkdtemp(prefix='virtinst-tmp')

Another reason to make this change is that requiring $HOME/.virtinst to
be world-readable guarantees that any vnc passwords will be readable
system-wide (via the log).

(Feel free to adjust the severity to wishlist if that seems more
 appropriate.)

Thanks

Rob Browning <rlb@defaultvalue.org> writes:

Oh, and of course I meant a "securely created *public* temp dir", which
I believe this should do by default.

And the umask would either have to be changed before the
tempfile.mkdtemp() call, or the directory's permissions would have to be
changed to 755 after.

Thanks

What uri are you using? In case of 'session' the qemu process is running
as your user so there shouldn't be a problem. Please run with --debug.
Cheers,
 -- Guido

Guido Günther <agx@sigxcpu.org> writes:

I just tested again.  Here are the commands:

  cd ~
  rm -rf .virtinst
  umask 027
  pool=/var/lib/libvirt/images
  virt-install --prompt -d --connect qemu:///system --virt-type kvm \
    --name test-vinstperms3 \
    --ram 256 \
    --disk path="$pool"/test-vinstperms3,format=raw,bus=virtio,size=2 \
    --network bridge=br0,model=virtio \
    --graphics vnc,password=whatever \
    --location http://ftp.debian.org/debian/dists/squeeze/main/installer-i386/

And here's the result:

  ...
  Sun, 05 Jun 2011 18:54:44 ERROR    internal error Process exited while reading console log output: char device redirected to /dev/pts/10
  qemu: could not load kernel '/home/rlb/.virtinst/boot/virtinst-linux.RdwkKK': Permission denied

  Sun, 05 Jun 2011 18:54:44 DEBUG    Traceback (most recent call last):
    File "/usr/bin/virt-install", line 1079, in start_install
      dom = guest.start_install(conscb, meter, wait=wait_on_console)
    File "/usr/lib/pymodules/python2.6/virtinst/Guest.py", line 1186, in start_install
      start_xml, final_xml, is_initial)
    File "/usr/lib/pymodules/python2.6/virtinst/Guest.py", line 1245, in _create_guest
      dom = self.conn.createLinux(start_xml or final_xml, 0)
    File "/usr/lib/python2.6/dist-packages/libvirt.py", line 1454, in createLinux
      if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self)
  libvirtError: internal error Process exited while reading console log output: char device redirected to /dev/pts/10
  qemu: could not load kernel '/home/rlb/.virtinst/boot/virtinst-linux.RdwkKK': Permission denied
  Sun, 05 Jun 2011 18:54:44 DEBUG    Domain installation does not appear to have been successful.

Thanks

I can confirm that this problem still exists and that the proposed
solution is IMHO adequate.

Hi,

Can you still reproduce this on current testing/sid?

I suspect this was fixed since then, as I see (1:1.0.1-2):

def _perform_initrd_injections(initrd, injections, scratchdir):
    """
    Insert files into the root directory of the initial ram disk
    """
[...]
    tempdir = tempfile.mkdtemp(dir=scratchdir)
    os.chmod(tempdir, 0775)

OTOH, the two other instances of tempfile.mkdtemp() I could see (in
virtconv/formats.py and virtinst/urlfetcher.py) have no such chmod, so
they may very well be affected by similar issues.

Cheers,
--
intrigeri

also sprach intrigeri <intrigeri@debian.org> [2014-10-09 12:30 +0200]:

The original bug report is about direct kernel loading by qemu,
unless I am very mistaken. So I don't think initrd injection code
fixes this.