qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: virtiofsd: sshfs as submount?


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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]