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
* 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
