[Virtio-fs] virtiofsd: sshfs as submount?

Max Reitz mreitz at redhat.com
Mon Dec 21 12:06:48 UTC 2020


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




More information about the Virtio-fs mailing list