I posted the below issue to the libvirt-users mailing list a few months ago but did not get any responses. Maybe it's better suited for this list. If anyone could tell me whether this is a bug, that'd be much appreciated.
Thank you!
----------------------------
I've run into an issue with 9p file sharing that I suspect is a bug. I'm running some Debian ARM VMs (armhf Ubuntu guests on an aarch64 Debian stretch host in case that matters). I'm using direct kernel boot, so I'm also using 9p host file sharing so that kernel updates from within the guest would work. However, I've noticed that dpkg (the Debian/Ubuntu package manager) fails when writing into a /boot directory that's shared from the host via 9p.
Some investigation reveals that this is because dpkg does an openat() call of the type
openat(AT_FDCWD, "/boot/vmlinuz-4.15.0-111-generic-lpae.dpkg-new", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 000);
and that it's the 0 permissions mode (last parameter) that causes the call to fail with a "Permission denied" error. A simple test program that does the above openat() call but with another mode (say, 600) works just fine.
Some further data:
* QEMU runs as the unprivileged user libvirt-qemu (Debian default)
* QEMU is version 2.8, libvirt version 3.0.0
* libvirt XML snippet for 9p setup:
<filesystem type='mount' accessmode='squash'>
<source dir='/host/path/boot-test9p'/>
<target dir='boot_mount'/>
<alias name='fs0'/>
<address type='pci' domain='0x0000' bus='0x03' slot='0x01' function='0x0'/>
</filesystem>
* The 9p filesystem is mounted by this line in /etc/fstab on the guest:
boot_mount /boot 9p rw,dirsync,_netdev,relatime,trans=virtio,version=9p2000.L 0 0
The essential problem seems to be that opening a file with a mode of 0 is not compatible with the "squash" 9p access mode. Is this expected?
Thank you,
Johan