| 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
| ||
|
Message-ID: <0cb769af0673ea1c28df7fa9a1cefe3ec23bc367.camel@kernel.org>
Date: Fri, 16 Jan 2026 10:13:52 -0500
From: Jeff Layton <jlayton@...nel.org>
To: Amir Goldstein <amir73il@...il.com>
Cc: Christian Brauner <brauner@...nel.org>, Alexander Viro
<viro@...iv.linux.org.uk>, Chuck Lever <chuck.lever@...cle.com>, NeilBrown
<neil@...wn.name>, Olga Kornievskaia <okorniev@...hat.com>, Dai Ngo
<Dai.Ngo@...cle.com>, Tom Talpey <tom@...pey.com>, Hugh Dickins
<hughd@...gle.com>, Baolin Wang <baolin.wang@...ux.alibaba.com>, Andrew
Morton <akpm@...ux-foundation.org>, Theodore Ts'o <tytso@....edu>, Andreas
Dilger <adilger.kernel@...ger.ca>, Jan Kara <jack@...e.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>, Carlos Maiolino <cem@...nel.org>, Ilya Dryomov
<idryomov@...il.com>, Alex Markuze <amarkuze@...hat.com>, Viacheslav
Dubeyko <slava@...eyko.com>, Chris Mason <clm@...com>, David Sterba
<dsterba@...e.com>, Luis de Bethencourt <luisbg@...nel.org>, Salah Triki
<salah.triki@...il.com>, Phillip Lougher <phillip@...ashfs.org.uk>, Steve
French <sfrench@...ba.org>, Paulo Alcantara <pc@...guebit.org>, Ronnie
Sahlberg <ronniesahlberg@...il.com>, Shyam Prasad N
<sprasad@...rosoft.com>, Bharath SM <bharathsm@...rosoft.com>, Miklos
Szeredi <miklos@...redi.hu>, Mike Marshall <hubcap@...ibond.com>, Martin
Brandenburg <martin@...ibond.com>, Mark Fasheh <mark@...heh.com>, Joel
Becker <jlbec@...lplan.org>, Joseph Qi <joseph.qi@...ux.alibaba.com>,
Konstantin Komarov <almaz.alexandrovich@...agon-software.com>, Ryusuke
Konishi <konishi.ryusuke@...il.com>, Trond Myklebust <trondmy@...nel.org>,
Anna Schumaker <anna@...nel.org>, Dave Kleikamp <shaggy@...nel.org>, David
Woodhouse <dwmw2@...radead.org>, Richard Weinberger <richard@....at>, Jan
Kara <jack@...e.cz>, Andreas Gruenbacher <agruenba@...hat.com>, OGAWA
Hirofumi <hirofumi@...l.parknet.co.jp>, Jaegeuk Kim <jaegeuk@...nel.org>,
Christoph Hellwig <hch@...radead.org>, linux-nfs@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-mm@...ck.org, linux-ext4@...r.kernel.org,
linux-erofs@...ts.ozlabs.org, linux-xfs@...r.kernel.org,
ceph-devel@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-cifs@...r.kernel.org, samba-technical@...ts.samba.org,
linux-unionfs@...r.kernel.org, devel@...ts.orangefs.org,
ocfs2-devel@...ts.linux.dev, ntfs3@...ts.linux.dev,
linux-nilfs@...r.kernel.org, jfs-discussion@...ts.sourceforge.net,
linux-mtd@...ts.infradead.org, gfs2@...ts.linux.dev,
linux-f2fs-devel@...ts.sourceforge.net
Subject: Re: [PATCH 29/29] nfsd: only allow filesystems that set
EXPORT_OP_STABLE_HANDLES
On Fri, 2026-01-16 at 15:46 +0100, Amir Goldstein wrote:
> On Fri, Jan 16, 2026 at 1:36 PM Jeff Layton <jlayton@...nel.org> wrote:
> >
> > On Thu, 2026-01-15 at 20:23 +0100, Amir Goldstein wrote:
> > > On Thu, Jan 15, 2026 at 6:51 PM Jeff Layton <jlayton@...nel.org> wrote:
> > > >
> > > > Some filesystems have grown export operations in order to provide
> > > > filehandles for local usage. Some of these filesystems are unsuitable
> > > > for use with nfsd, since their filehandles are not persistent across
> > > > reboots.
> > > >
> > > > In __fh_verify, check whether EXPORT_OP_STABLE_HANDLES is set
> > > > and return nfserr_stale if it isn't.
> > > >
> > > > Signed-off-by: Jeff Layton <jlayton@...nel.org>
> > > > ---
> > > > fs/nfsd/nfsfh.c | 4 ++++
> > > > 1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/fs/nfsd/nfsfh.c b/fs/nfsd/nfsfh.c
> > > > index ed85dd43da18e6d4c4667ff14dc035f2eacff1d6..da9d5fb2e6613c2707195da2e8678b3fcb3d444d 100644
> > > > --- a/fs/nfsd/nfsfh.c
> > > > +++ b/fs/nfsd/nfsfh.c
> > > > @@ -334,6 +334,10 @@ __fh_verify(struct svc_rqst *rqstp,
> > > > dentry = fhp->fh_dentry;
> > > > exp = fhp->fh_export;
> > > >
> > > > + error = nfserr_stale;
> > > > + if (!(dentry->d_sb->s_export_op->flags & EXPORT_OP_STABLE_HANDLES))
> > > > + goto out;
> > > > +
> > > > trace_nfsd_fh_verify(rqstp, fhp, type, access);
> > > >
> > >
> > > IDGI. Don't you want to deny the export of those fs in check_export()?
> > > By the same logic that check_export() checks for can_decode_fh()
> > > not for can_encode_fh().
> > >
> >
> > It certainly won't hurt to add a check for this to check_export(), and
> > I've gone ahead and done so. To be clear, doing that won't prevent the
> > filesystem from being exported, but you will get a warning like this
> > when you try:
> >
> > exportfs: /sys/fs/cgroup does not support NFS export
> >
> > That export will still show up in mountd though, so this is just a
> > warning. Trying to mount it though will fail.
> >
>
> Oh, I did not know. What an odd user experience.
> Anyway, better than no warning at all.
>
Indeed.
The catch is that this won't catch all scenarios where that fs could be
exported. If you do something like this in /etc/exports:
/ *(rw,crossmnt,insecure,no_root_squash)
...you won't see a warning. Granted, doing the above is _dumb_ but it
illustrates that it's not possible to completely vet the export table.
Even if you could, it could change out from under you.
We do have some ideas about updating the export management, but nothing
concrete yet. Even then, we'll need to maintain backward compatibility,
so I doubt we can change the user experience in a fundamental way at
this point.
--
Jeff Layton <jlayton@...nel.org>
Powered by blists - more mailing lists