Bug 1346100 - "permission denied" passthrough 9p filesystem share
Summary: "permission denied" passthrough 9p filesystem share
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 23
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-06-14 01:58 UTC by Adam Chasen
Modified: 2016-06-15 01:37 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-06-15 01:37:46 UTC
Type: Bug

Attachments (Terms of Use)

Description Adam Chasen 2016-06-14 01:58:24 UTC
Description of problem:
Mounted "passthrough" 9p filesystem share in qemu:///system does not have write access.


Steps to Reproduce:
1. mkdir /share
2. semanage fcontext -a -t svirt_image_t "/share(/.*)?"
3. restorecon -vR /share
4. add the following to KVM libvirt domain:
 <filesystem type='mount' accessmode='passthrough'>
      <source dir='/share'/>
      <target dir='test'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/>
5. boot domain (happens to be a coreos instance)
6. mount share: sudo mount test -t 9p /mnt/
7. read successful
8. attempt to write or modify

Actual results:
"permission denied"

Expected results:
write successful

Comment 1 Cole Robinson 2016-06-14 11:23:15 UTC
does accessmode=mapped make any difference? passthrough tries to do a setuid($VMUSER) on the host side, which requires admin access on the host which default configured libvirt VMs usually don't have. mapped will have the files owned as 'qemu:qemu' on the host, but at least you can read/write

Comment 2 Adam Chasen 2016-06-15 01:37:46 UTC
Initially the directory was root:root which resulted in permission denied erros. After setting directory ownership of /share to qemu:qemu, I was able to write to the directory from inside the domain(yay!), but not until I powered off the guest and powered it back on.

Note, the created file has selinux user of "system_u" files created my me manually on the host with qemu:qemu 644 are "unconfined_u". Not sure if this matters.

Thank you for the pointer to "mapped" mode! For some reason I thought the libvirt VMs had admin access (but were limited by selinux), good to hear they are limited both ways.

Note You need to log in before you can comment on or make changes to this bug.