Re: [RFC 0/2] fuse: introduce fuse server recovery mechanism

[Christian Brauner <brauner@kernel.org>]

On Tue, May 28, 2024 at 12:02:46PM +0800, Gao Xiang wrote:
> 
> 
> On 2024/5/28 11:08, Jingbo Xu wrote:
> > 
> > 
> > On 5/28/24 10:45 AM, Jingbo Xu wrote:
> > > 
> > > 
> > > On 5/27/24 11:16 PM, Miklos Szeredi wrote:
> > > > On Fri, 24 May 2024 at 08:40, Jingbo Xu <jefflexu@linux.alibaba.com> wrote:
> > > > 
> > > > > 3. I don't know if a kernel based recovery mechanism is welcome on the
> > > > > community side.  Any comment is welcome.  Thanks!
> > > > 
> > > > I'd prefer something external to fuse.
> > > 
> > > Okay, understood.
> > > 
> > > > 
> > > > Maybe a kernel based fdstore (lifetime connected to that of the
> > > > container) would a useful service more generally?
> > > 
> > > Yeah I indeed had considered this, but I'm afraid VFS guys would be
> > > concerned about why we do this on kernel side rather than in user space.
> 
> Just from my own perspective, even if it's in FUSE, the concern is
> almost the same.
> 
> I wonder if on-demand cachefiles can keep fds too in the future
> (thus e.g. daemonless feature could even be implemented entirely
> with kernel fdstore) but it still has the same concern or it's
> a source of duplication.
> 
> Thanks,
> Gao Xiang
> 
> > > 
> > > I'm not sure what the VFS guys think about this and if the kernel side
> > > shall care about this.

Fwiw, I'm not convinced and I think that's a big can of worms security
wise and semantics wise. I have discussed whether a kernel-side fdstore
would be something that systemd would use if available multiple times
and they wouldn't use it because it provides them with no benefits over
having it in userspace.

Especially since it implements a lot of special semantics and policy
that we really don't want in the kernel. I think that's just not
something we should do. We should give userspace all the means to
implement fdstores in userspace but not hold fds ourselves.