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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240528-pegel-karpfen-fd16814adc50@brauner>
Date: Tue, 28 May 2024 10:43:15 +0200
From: Christian Brauner <brauner@...nel.org>
To: Gao Xiang <hsiangkao@...ux.alibaba.com>
Cc: Jingbo Xu <jefflexu@...ux.alibaba.com>, 
	Miklos Szeredi <miklos@...redi.hu>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, 
	winters.zc@...group.com
Subject: Re: [RFC 0/2] fuse: introduce fuse server recovery mechanism

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@...ux.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.