Description of problem:
Mounted "passthrough" 9p filesystem share in qemu:///system does not have write access.
libvirt-daemon-1.2.18.3-1.fc23.x86_64
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'/>
</filesystem>
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
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
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.
Description of problem: Mounted "passthrough" 9p filesystem share in qemu:///system does not have write access. libvirt-daemon-1.2.18.3-1.fc23.x86_64 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'/> </filesystem> 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