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: <CAOQ4uxhMjitW_DC9WK9eku51gE1Ft+ENhD=qq3uehwrHO=RByA@mail.gmail.com>
Date: Wed, 14 Jan 2026 10:34:04 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: 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, 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.

This problem is old and welded into the system, but IMO adding more
kernel filesystems, which consciously export file handles that do not
survive server reboot does not serve users interests well.

One could claim that this is a bug that can be fixed by adding boot_id
to said file handles, but why fix something that nobody asked for?

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?

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.

Thanks,
Amir.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ