Message-ID: <20260114133955.0a9f5cd3@pumpkin>
Date: Wed, 14 Jan 2026 13:39:55 +0000
From: David Laight <david.laight.linux@...il.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: Christoph Hellwig <hch@...radead.org>, Jeff Layton <jlayton@...nel.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, 14 Jan 2026 10:34:04 +0100
Amir Goldstein <amir73il@...il.com> 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.
> 
> 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.
> 
> FUSE will gladly open a completely different object, sometimes
> a different object type from an NFS client request after server restart.
> 
> I suppose that the same could happen with tmpfs and probably some
> other fs.
...

You really shouldn't be allowed to nfs export a fs that doesn't have
persistent file handles.

Even file handles containing 'random' numbers can be problematic.
The default used to be 'hard mounts' (not sure it is any more) which
caused the client (not Linux - too long ago) to loop in kernel
forever waiting for the server to recover the filesystem export.
The only resolution on that system was to reboot the client.

At least nfs can now use variable size file-ids.
When I was fixing some code that exported a layered fs (I pretty
much rewrote the fs at the same time) I did randomise the file-ids
so they (hopefully) became invalid after a reboot (only after suffering
some very corrupt filesystems!)
I found nfs (over udp) had some interesting 'features':
- If you export part of a fs you export all of it.
  (Especially since this predated the randomisation of the inode
  generation number.)
- If you give anyone access you give everyone access.
- If you give anyone write access you give everyone write access.
The latter two because the 'mount' protocol wasn't really needed
and the server didn't care where requests came from.

	David

Powered by blists - more mailing lists