Message-ID: <CAOQ4uxhDwR7dteLaqURX+9CooGM1hA7PL6KnVmSwX11ZdKxZTA@mail.gmail.com>
Date: Wed, 14 Jan 2026 15:14:13 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Jeff Layton <jlayton@...nel.org>
Cc: Christoph Hellwig <hch@...radead.org>, Christian Brauner <brauner@...nel.org>, 
	Chuck Lever <chuck.lever@...cle.com>, Jan Kara <jack@...e.cz>, 
	Luis de Bethencourt <luisbg@...nel.org>, Salah Triki <salah.triki@...il.com>, 
	Nicolas Pitre <nico@...xnic.net>, Anders Larsen <al@...rsen.net>, 
	Alexander Viro <viro@...iv.linux.org.uk>, David Sterba <dsterba@...e.com>, Chris Mason <clm@...com>, 
	Gao Xiang <xiang@...nel.org>, Chao Yu <chao@...nel.org>, Yue Hu <zbestahu@...il.com>, 
	Jeffle Xu <jefflexu@...ux.alibaba.com>, Sandeep Dhavale <dhavale@...gle.com>, 
	Hongbo Li <lihongbo22@...wei.com>, Chunhai Guo <guochunhai@...o.com>, Jan Kara <jack@...e.com>, 
	"Theodore Ts'o" <tytso@....edu>, Andreas Dilger <adilger.kernel@...ger.ca>, 
	Jaegeuk Kim <jaegeuk@...nel.org>, OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>, 
	David Woodhouse <dwmw2@...radead.org>, Richard Weinberger <richard@....at>, Dave Kleikamp <shaggy@...nel.org>, 
	Ryusuke Konishi <konishi.ryusuke@...il.com>, Viacheslav Dubeyko <slava@...eyko.com>, 
	Konstantin Komarov <almaz.alexandrovich@...agon-software.com>, Mark Fasheh <mark@...heh.com>, 
	Joel Becker <jlbec@...lplan.org>, Joseph Qi <joseph.qi@...ux.alibaba.com>, 
	Mike Marshall <hubcap@...ibond.com>, Martin Brandenburg <martin@...ibond.com>, 
	Miklos Szeredi <miklos@...redi.hu>, Phillip Lougher <phillip@...ashfs.org.uk>, 
	Carlos Maiolino <cem@...nel.org>, Hugh Dickins <hughd@...gle.com>, 
	Baolin Wang <baolin.wang@...ux.alibaba.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Namjae Jeon <linkinjeon@...nel.org>, Sungjong Seo <sj1557.seo@...sung.com>, 
	Yuezhang Mo <yuezhang.mo@...y.com>, Alexander Aring <alex.aring@...il.com>, 
	Andreas Gruenbacher <agruenba@...hat.com>, Jonathan Corbet <corbet@....net>, 
	"Matthew Wilcox (Oracle)" <willy@...radead.org>, Eric Van Hensbergen <ericvh@...nel.org>, 
	Latchesar Ionkov <lucho@...kov.net>, Dominique Martinet <asmadeus@...ewreck.org>, 
	Christian Schoenebeck <linux_oss@...debyte.com>, Xiubo Li <xiubli@...hat.com>, 
	Ilya Dryomov <idryomov@...il.com>, Trond Myklebust <trondmy@...nel.org>, 
	Anna Schumaker <anna@...nel.org>, Steve French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.org>, 
	Ronnie Sahlberg <ronniesahlberg@...il.com>, Shyam Prasad N <sprasad@...rosoft.com>, 
	Tom Talpey <tom@...pey.com>, Bharath SM <bharathsm@...rosoft.com>, 
	Hans de Goede <hansg@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-btrfs@...r.kernel.org, 
	linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org, 
	linux-f2fs-devel@...ts.sourceforge.net, linux-mtd@...ts.infradead.org, 
	jfs-discussion@...ts.sourceforge.net, linux-nilfs@...r.kernel.org, 
	ntfs3@...ts.linux.dev, ocfs2-devel@...ts.linux.dev, devel@...ts.orangefs.org, 
	linux-unionfs@...r.kernel.org, linux-xfs@...r.kernel.org, linux-mm@...ck.org, 
	gfs2@...ts.linux.dev, linux-doc@...r.kernel.org, v9fs@...ts.linux.dev, 
	ceph-devel@...r.kernel.org, linux-nfs@...r.kernel.org, 
	linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org
Subject: Re: [PATCH 00/24] vfs: require filesystems to explicitly opt-in to
 lease support

On Wed, Jan 14, 2026 at 2:41 PM Jeff Layton <jlayton@...nel.org> wrote:
>
> On Wed, 2026-01-14 at 05:06 -0800, Christoph Hellwig wrote:
> > On Wed, Jan 14, 2026 at 10:34:04AM +0100, Amir Goldstein wrote:
> > > On Wed, Jan 14, 2026 at 7:28 AM Christoph Hellwig <hch@...radead.org> wrote:
> > > >
> > > > On Tue, Jan 13, 2026 at 12:06:42PM -0500, Jeff Layton wrote:
> > > > > Fair point, but it's not that hard to conceive of a situation where
> > > > > someone inadvertantly exports cgroupfs or some similar filesystem:
> > > >
> > > > Sure.  But how is this worse than accidentally exporting private data
> > > > or any other misconfiguration?
> > > >
> > >
> > > My POV is that it is less about security (as your question implies), and
> > > more about correctness.
> >
> > I was just replying to Jeff.
> >
> > > The special thing about NFS export, as opposed to, say, ksmbd, is
> > > open by file handle, IOW, the export_operations.
> > >
> > > I perceive this as a very strange and undesired situation when NFS
> > > file handles do not behave as persistent file handles.
> >
> > That is not just very strange, but actually broken (discounting the
> > obscure volatile file handles features not implemented in Linux NFS
> > and NFSD).  And the export ops always worked under the assumption
> > that these file handles are indeed persistent.  If they're not we
> > do have a problem.
> >
> > >
> > > cgroupfs, pidfs, nsfs, all gained open_by_handle_at() capability for
> > > a known reason, which was NOT NFS export.
> > >
> > > If the author of open_by_handle_at() support (i.e. brauner) does not
> > > wish to imply that those fs should be exported to NFS, why object?
> >
> > Because "want to export" is a stupid category.
> >
> > OTOH "NFS exporting doesn't actually properly work because someone
> > overloaded export_ops with different semantics" is a valid category.
> >
>
> cgroupfs definitely doesn't behave as expected when exported via NFS.
> The files aren't readable, at least. I'd also be surprised if the
> filehandles were stable across a reboot, which is sort of necessary for
> proper operation. I didn't test writing, but who knows whether that
> might also just not work, crash the box, or do something else entirely.
>
> I imagine this is the case for all sorts of filesystems like /proc,
> /sys, etc. Those aren't exportable today (to my knowledge), but we're
> growing export_operations across a wide range of fs's these days.
>
> I'd prefer that we require someone to take the deliberate step to say
> "yes, allow nfsd to access this type of filesystem".
>
> > > We could have the opt-in/out of NFS export fixes per EXPORT_OP_
> > > flags and we could even think of allowing admin to make this decision
> > > per vfsmount (e.g. for cgroupfs).
> > >
> > > In any case, I fail to see how objecting to the possibility of NFS export
> > > opt-out serves anyone.
> >
> > You're still think of it the wrong way.  If we do have file systems
> > that break the original exportfs semantics we need to fix that, and
> > something like a "stable handles" flag will work well for that.  But
> > a totally arbitrary "is exportable" flag is total nonsense.
>

Very well then.
How about EXPORT_OP_PERSISTENT_HANDLES?

This terminology is from the NFS protocol spec and it is also used
to describe the same trait in SMB protocol.

> The problem there is that we very much do want to keep tmpfs
> exportable, but it doesn't have stable handles (per-se).

Thinking out loud -
It would be misguided to declare tmpfs as
EXPORT_OP_PERSISTENT_HANDLES
and regressing exports of tmpfs will surely not go unnoticed.

How about adding an exportfs option "persistent_handles",
use it as default IFF neither options fsid=, uuid= are used,
so that at least when exporting tmpfs, exportfs -v will show
"no_persistent_handles" explicitly?

Thanks,
Amir.

Powered by blists - more mailing lists