[Pkg-libvirt-maintainers] Bug#781283: Bug#781283: libvirt-bin: Permission denied with 9p file system

[Boylan, Ross]

I don't know what you mean by "proxy filesystem."

I tried to change it so kvm runs as root, but the libvirt daemon seems to fail as soon as virt-manager tries to contact it. I don't see anything even written to the system logs at that time, and my .xsession-errors has only the usual noise (this is running as a regular user that is in the libvirt group):
<.xsession-errors>
/usr/share/virt-manager/virt-manager.py:306: DeprecationWarning: Importing dbus.glib to use the GLib main loop with dbus-python is deprecated.
Instead, use this sequence:
  
    from dbus.mainloop.glib import DBusGMainLoop
  
    DBusGMainLoop(set_as_default=True)
  
  import dbus.glib
</.xsession-errors>

More details:
Edited /etc/libvirt/qemu.conf so that clear_emulator_capabilities = 0.  I thought this might cause kvm to run as root (it didn't) and hoped that it would help with bridged networking problems (it seemed to).  I shutdown all the VMs and restarted libvirt to test.
Added
user=root
group=root
to qemu.conf and /etc/init.d/libvirt-bin
When I started virt-manager it said it could not contact libvirt
<error>
Unable to connect to libvirt.

Cannot recv data: Connection reset by peer

Libvirt URI is: qemu:///system

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/connection.py", line 1185, in _open_thread
    self.vmm = self._try_open()
  File "/usr/share/virt-manager/virtManager/connection.py", line 1167, in _try_open
    flags)
  File "/usr/lib/python2.7/dist-packages/libvirt.py", line 102, in openAuth
    if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: Cannot recv data: Connection reset by peer
</error>
And /etc/init.d/libvirt-bin status says "libvirtd not running failed!".  The same status request run immediately before the virt-manager launch show libvirtd is running.
I repeated this exercise several times, always with the same result.

Finally, a couple comments on my original report.  I thought that kvm was running as root because libvirtd was; instead it's libvirt-qemu as you said.  This makes some of the permission problems I was having more understandable.

P.S.  I tried running virt-manager from root, and got the same failure.
________________________________________
From: Guido Günther [agx at sigxcpu.org]
Sent: Tuesday, March 31, 2015 1:25 AM
To: Boylan, Ross
Cc: 781283 at bugs.debian.org; rossboylan at stanfordalumni.org
Subject: Re: [Pkg-libvirt-maintainers] Bug#781283: libvirt-bin: Permission denied with 9p file system

On Fri, Mar 27, 2015 at 04:49:43PM +0000, Boylan, Ross wrote:
> Thanks for the fast response.
>
> The UID's match on host and guest.  Notice that the problems with directory listing occurred as root (UID 0).  The copy problem was as ross.  Most of the files are owned by ross (UID 1000).
>
> Eventually,  I'll want to operate from the guest with a UID not present on the host, although I could add it to the host if necessary.
>
> Although it's possible this is a KVM issue, a significant number of similar problems reported on the net were the result of libvirt, usually the security framework (selinux or apparmor--are either relevant for Debian?), but sometimes also the exact mode choices.  The fact that I can't access host files as root from the guest, with libvirt daemon running as root (I think) on the host suggests something is getting in the way.  The apparent logic is "group and  other have no access rights to the file; file's owner UID = 1000; accessing process UID=0; no acesss."

Using accessmode=mapped works fine if the directory/files are writeable
by the user running libvirt (libvirt-qemu by default). For passthrough
run kvm/qemu as root.
Proxy filesystem is currently not supported by libvirt.
Cheers,
 -- Guido