Operating inside a wheezy VM with fstab including
SASInstaller    /mnt/SASInstaller   9p  trans=virtio,version=9p2000.L 0 0
SASUnzip        /mnt/SASUnzip   9p  trans=virtio,version=9p2000.L 0 0
and libvirt setup with, e.g.,
    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/SASInstaller'/>
      <target dir='SASInstaller'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a'
function='0x0'/>
    </filesystem>
Using KVM.

I get lots of "Permission Denied" errors both when listing directory
contents and when trying to do anything, such as creating a file.
E.g.,

ross@markov02:/mnt/SASUnzip$ cp ../SASInstaller/*txt sid_files/
cp: cannot create regular file
`sid_files/SAS94_9B1RJ4_70081229_Win_X64_Wrkstn.txt': Permission
denied

It seems that operations are not allowed unless root on the host has
explicit permission to do the operation, even if I am user "ross" on
both host and VM (same uid also).  Being root on the guest doesn't
help.

One oddity is that the the ability of ls to list the files attributes
seems to depend on read access to the file, not to the directory in
which the file resides.  Here's an example, as root from the guest:
<terminal>
root@markov02:/mnt/SASInstaller# ls -l
ls: cannot access lost+found: Permission denied
ls: cannot access Linux64-L25415-8384TMP.zip: Permission denied
ls: cannot access Windows64-L25415-5264TMP.zip: Permission denied
total 16
-????????? ? ?    ?       ?            ? Linux64-L25415-8384TMP.zip
d????????? ? ?    ?       ?            ? lost+found
-rw-r--r-- 1 ross ross 5581 Mar 25 14:39
SAS94_9B1RJ4_70081229_Win_X64_Wrkstn.txt
-rw-r--r-- 1 ross ross 5417 Mar 26 10:41 SAS94_9B1RJ4_70081487_LINUX_X86-64.txt
-????????? ? ?    ?       ?            ? Windows64-L25415-5264TMP.zip
root@markov02:/mnt/SASInstaller# ls -ld .
drwxr-xr-x 3 ross root 4096 Mar 26 10:41 .
root@markov02:/mnt/SASInstaller# # changed first file to allow reads
from everyone
root@markov02:/mnt/SASInstaller# date; ls -l
Thu Mar 26 12:16:51 PDT 2015
ls: cannot access lost+found: Permission denied
ls: cannot access Windows64-L25415-5264TMP.zip: Permission denied
total 18215208
-rw-r--r-- 1 ross ross 18652350572 Jan  9 16:50 Linux64-L25415-8384TMP.zip
d????????? ? ?    ?              ?            ? lost+found
-rw-r--r-- 1 ross ross        5581 Mar 25 14:39
SAS94_9B1RJ4_70081229_Win_X64_Wrkstn.txt
-rw-r--r-- 1 ross ross        5417 Mar 26 10:41
SAS94_9B1RJ4_70081487_LINUX_X86-64.txt
-????????? ? ?    ?              ?            ? Windows64-L25415-5264TMP.zip
</terminal>

There are tons of reports like this on the internet, blaming various
components: apparmor (esp for Ubuntu), selinux, the kernel (3.5 was
mentioned as buggy), libvirt.  I'm not sure where the problem lies; it
doesn't seem apparmor or selinux are active for me (host and guest are
pretty vanilla).

Expected behavior: that the 9p mount should behave exactly the same as
the underlying file system.  This include root on guest being root on
host, though I can see there might be reasons to avoid this.

Ross Boylan

Hi Ross,

You need to have matching UIDs in the VM and the host - is that the case? It's working fine
over here since years so it's likely a setup problem on your end.

That said these kind of bugs are better suited for QEMU/KVM since
libvirt only does the setup and QEMU is carrying the actual 9pfs implementation.

Cheers,
 -- Guido

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."

Ross


You need to have matching UIDs in the VM and the host - is that the case? It's working fine
over here since years so it's likely a setup problem on your end.

That said these kind of bugs are better suited for QEMU/KVM since
libvirt only does the setup and QEMU is carrying the actual 9pfs implementation.

Cheers,
 -- Guido

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

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.


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

I have managed to workaround this issue with the following settings in /etc/libvirt/qemu.conf:

clear_emulator_capabilities = 0
user = "root"
group = "root"

This is tested using a KVM virtual machine (Debian Stretch) with the following definintion:

    <filesystem type='mount' accessmode='passthrough'>
      <source dir='/mnt/share'/>
      <target dir='share'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
    </filesystem>

and the following /etc/fstab entry

share      /mnt/share/       9p  rw,nodev,relatime,sync,dirsync,access=client,trans=virtio    0 0

I tried a number of different permission settings before disabling clear_emulator_capabilities.
However, this was the only way to permit permission changes to files or normal users (apart from root) to own files.

I am concerned by the potential security implications of this change as it may expose higher privileges for the guest KVM machines.
It would be great if there were a way to support 9pfs passthrough without escalating privilegs using this setting.