Re: virtiofsd: sshfs as submount?

[Laszlo Ersek]

On 12/21/20 13:06, Max Reitz wrote:
> 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)

:)

Thank you, Max!
Laszlo

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