No write access in a 9p/virtfs shared folder

Bug #1018530 reported by Georg Poppe on 2012-06-27
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
QEMU
Undecided
Unassigned
qemu-kvm (Ubuntu)
Medium
Unassigned

Bug Description

Ubuntu version: Ubuntu 12.04 LTS
Kernel: 3.2.0-25-generic
Version of qemu-kvm: 1.0+noroms-0ubuntu13

I have created an shared folder for an virtual machine which is managed by libvirt.

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

I mounted it in the virtual machine with this command: mount -t 9p -o trans=virtio,version=9p2000.L data /data
The filesystem permissions of all files an folders in the shared folder are set to 777. I expected that I have the full permissions also in the virtual machine.

Regardless of the permissions on the filesystem I cannot write or create files and folders in the virtual machine. The original filesystem (/storage) is XFS.
In another shared folder (similar config in libvirt) which is originally NTFS I have no problems.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: qemu-kvm 1.0+noroms-0ubuntu13
ProcVersionSignature: Ubuntu 3.2.0-25.40-generic 3.2.18
Uname: Linux 3.2.0-25-generic x86_64
ApportVersion: 2.0.1-0ubuntu8
Architecture: amd64
Date: Wed Jun 27 20:15:20 2012
InstallationMedia: Ubuntu-Server 12.04 LTS "Precise Pangolin" - Beta amd64 (20120409)
MachineType: To be filled by O.E.M. To be filled by O.E.M.
ProcEnviron:
 TERM=xterm
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.2.0-25-generic root=/dev/mapper/system-root ro
SourcePackage: qemu-kvm
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/18/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 1208
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: M5A99X EVO
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr1208:bd04/18/2012:svnTobefilledbyO.E.M.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnASUSTeKCOMPUTERINC.:rnM5A99XEVO:rvrRev1.xx:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To be filled by O.E.M.
dmi.product.version: To be filled by O.E.M.
dmi.sys.vendor: To be filled by O.E.M.

Georg Poppe (georg-poppe-) wrote :
Serge Hallyn (serge-hallyn) wrote :

Thanks for reporting this bug. Could you check your /var/log/syslog for apparmor messages relating to libvirt accessing /data? The command

   sudo grep DENIED /var/log/syslog | grep libvirt

should return interesting results.

Changed in qemu-kvm (Ubuntu):
importance: Undecided → Medium
status: New → Incomplete
Georg Poppe (georg-poppe-) wrote :

No, there are no results relating /data. I would have wondered about it, because I already configured apparmor to allow access to /data. The current rules in the profile of the virtual machine are
  "/storage/data/" rw,
  "/storage/data/**" rw,

I also disabled the apparmor profile but it didn't help either.

Serge Hallyn (serge-hallyn) wrote :

I can confirm this does not work in precise, however it looks like creating files (and directories etc) was not implemented in qemu-kvm 1.0. File creation was added with commit daf0b9aca9f67323266af1a92e8ea06f9d7bf408 .

This should work in quantal - if it does not, then that is a new bug. However adding a new feature in an SRU (especially to LTS) would be hard to justify.

Changed in qemu-kvm (Ubuntu):
status: Incomplete → Fix Released
M. Mohan Kumar (mohan-6) wrote :

No, commit daf0b9aca9f67323266af1a92e8ea06f9d7bf408 added create support proxy FS driver model. Local FS had support for creating files much before.

Georg, is qemu running with root user privileges?

Georg Poppe (georg-poppe-) wrote :

qemu is running with user libvirt-qemu, not root.

Quoting M. Mohan Kumar (<email address hidden>):
> No, commit daf0b9aca9f67323266af1a92e8ea06f9d7bf408 added create
> support proxy FS driver model. Local FS had support for creating files
> much before.

Yes, but that commit is not in v1.0 (according to qemu-kvm git
history at least)

M. Mohan Kumar (mohan-6) wrote :

Georg,

pass-through security model needs root privilege, if you want to run qemu as non-root user either you have to use mapped security model or proxy fs driver. But libvirt does not have support for proxy FS driver. I posted a patch few months ago to libvirt for enabling the same. I will do the followup with libvirt list to enable proxy FS in libvirt.

So could you please try mapped security model or run qemu as root user and update the results?

Georg Poppe (georg-poppe-) wrote :

Okay, it is working now. I am using the mapped security model but I wanted to avoid it at first.
I hope proxy FS will be supported in quantal.

But I am still wondering why passthrough security is working smoothly with NTFS-3G.

With passthrough security model creation files in guest still doesn't work in Raring.

QEMU version is 1.4.0,
AppArmor folder rules added to libvirt profile of tested VM,
Permissions on testing folder is 777.

Serge Hallyn (serge-hallyn) wrote :

Please file a new bug using 'ubuntu-bug libvirt-bin', providing details on the setup and how it is failing.

Thomas Huth (th-huth) wrote :

Sounds like this was an Ubuntu- or libvirt-specific bug ... so closing this in the upstream QEMU bug tracker.

Changed in qemu:
status: New → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers