|
From: | Max Reitz |
Subject: | Re: virtiofsd: sshfs as submount? |
Date: | Mon, 21 Dec 2020 13:06:48 +0100 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 |
On 20.12.20 00:41, Laszlo Ersek wrote:
Hi Miklos,
(I hope it’s OK for me not to be Miklos, even though I don’t have much to add)
the following 2019 presentation on Stefan's website: https://vmsplice.net/ virtio-fs: A Shared File System for Virtual Machines at KVM Forum 2019 https://vmsplice.net/~stefan/virtio-fs_%20A%20Shared%20File%20System%20for%20Virtual%20Machines.pdf has a slide called "Use case: File system-as-a-service" (slide#4). It seems to confirm my "grand" idea to expose an sshfs submount to the guest, via virtiofsd. (The guest need not / should not know it's a submount, just see the files.) Beyond the pure utility of this, it feels exciting to chain FUSE to FUSE. :) I've tried it; the FUSE_READDIRPLUS request fails. [2020-12-20 00:32:08.64+0100] [ID: 00000006] unique: 83, opcode: READDIRPLUS (44), nodeid: 1, insize: 80, pid: 1 [2020-12-20 00:32:08.64+0100] [ID: 00000006] unique: 83, error: -13 (Permission denied), outsize: 16 More precisely, it fails on the directory entry in the containing directory that is the sshfs mount point, when listing the containing directory.
I see the same.
I've skimmed the following thread: [PATCH] virtiofsd: Show submounts https://www.redhat.com/archives/virtio-fs/2020-April/msg00023.html (which is now QEMU commit ace0829c0d08), and I vaguely suspect it should work -- the MS_REC flag is present, and the MS_REC flag seems to be so old that I think my host kernel (latest RHEL7) must support it too.
It works (for me) with other mounts (like XFS or ext4), so submounts shouldn’t be the problem.
So... does the sshfs filesystem present itself as unshareable? Is it supposed to work? Does it break for others too?
I can share sshfs through sshfs, so it must be something virtiofs-specific.I tried to debug it, but I could only find that the fstatat()/statx() on it (FD opened, then stat called with that FD, an empty pathname, and AT_EMPTY_PATH | AT_SYMLINK_NOFOLLOW) fails with EPERM. I tried disabling all the sandboxing, but still got that error.
FWIW, I get the same error with virtiofsd-rs (and there, too, the fstatat64() yields the EPERM).
So far, I couldn’t reproduce it outside of virtiofsd, though... (Like, just invoking stat on the command line works; and a simple program that opens the mount point FD and then stats it works, too.)
Max
[Prev in Thread] | Current Thread | [Next in Thread] |