[PATCH] nfsd: do not allow exporting of special kernel filesystems

[PATCH] nfsd: do not allow exporting of special kernel filesystems

[Amir Goldstein]

pidfs and nsfs recently gained support for encode/decode of file handles
via name_to_handle_at(2)/opan_by_handle_at(2).

These special kernel filesystems have custom ->open() and ->permission()
export methods, which nfsd does not respect and it was never meant to be
used for exporting those filesystems by nfsd.

Therefore, do not allow nfsd to export filesystems with custom ->open()
or ->permission() methods.

Fixes: b3caba8f7a34a ("pidfs: implement file handle support")
Fixes: 5222470b2fbb3 ("nsfs: support file handles")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 fs/nfsd/export.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

Christian,

I had enough of the stable file handles discussion [1].

This patch which I already suggested [2] on week ago, states a justified
technical reason why pidfs and nsfs should not be exported by nfsd,
so let's use this technical reasoning and stop the philosophic discussions
about what is a stable file handle is please.

Regarding cgroupfs, we can either deal with it later or not - it is not
a clear but as pidfs and nsfs which absolutely should be fixed
retroactively in stable kernels.

If you think that cgroupfs could benefit from "exhaustive" file handles [3]
then we can implement open_by_handle_at(FD_CGROUPFS_ROOT, ... and that
would classify cgroupfs the same as pidfs and nsfs.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-0-1a247645cef5@kernel.org/
[2] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhkaGFtQRzTj2xaf2GJucoAY5CGiyUjB=8YA2zTbOtFvw@mail.gmail.com/
[3] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-29-1a247645cef5@kernel.org/

diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
index 2a1499f2ad196..232dacac611e9 100644
--- a/fs/nfsd/export.c
+++ b/fs/nfsd/export.c
@@ -405,6 +405,7 @@ static struct svc_export *svc_export_lookup(struct svc_export *);
 static int check_export(const struct path *path, int *flags, unsigned char *uuid)
 {
 	struct inode *inode = d_inode(path->dentry);
+	const struct export_operations *nop = inode->i_sb->s_export_op;
 
 	/*
 	 * We currently export only dirs, regular files, and (for v4
@@ -422,13 +423,12 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
 	if (*flags & NFSEXP_V4ROOT)
 		*flags |= NFSEXP_READONLY;
 
-	/* There are two requirements on a filesystem to be exportable.
-	 * 1:  We must be able to identify the filesystem from a number.
-	 *       either a device number (so FS_REQUIRES_DEV needed)
-	 *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
-	 * 2:  We must be able to find an inode from a filehandle.
-	 *       This means that s_export_op must be set.
-	 * 3: We must not currently be on an idmapped mount.
+	/*
+	 * The requirements for a filesystem to be exportable:
+	 * 1. The filehandle must identify a filesystem by number
+	 * 2. The filehandle must uniquely identify an inode
+	 * 3. The filesystem must not have custom filehandle open/perm methods
+	 * 4. The requested file must not reside on an idmapped mount
 	 */
 	if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
 	    !(*flags & NFSEXP_FSID) &&
@@ -437,11 +437,16 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
 		return -EINVAL;
 	}
 
-	if (!exportfs_can_decode_fh(inode->i_sb->s_export_op)) {
+	if (!exportfs_can_decode_fh(nop)) {
 		dprintk("exp_export: export of invalid fs type.\n");
 		return -EINVAL;
 	}
 
+	if (nop->open || nop->permission) {
+		dprintk("exp_export: export of non-standard fs type.\n");
+		return -EINVAL;
+	}
+
 	if (is_idmapped_mnt(path->mnt)) {
 		dprintk("exp_export: export of idmapped mounts not yet supported.\n");
 		return -EINVAL;
-- 
2.52.0

Re: [PATCH] nfsd: do not allow exporting of special kernel filesystems

[Amir Goldstein]

[cc the correct email address for Neil]

On Wed, Jan 21, 2026 at 9:50 AM Amir Goldstein <amir73il@gmail.com> wrote:
>
> pidfs and nsfs recently gained support for encode/decode of file handles
> via name_to_handle_at(2)/opan_by_handle_at(2).
>
> These special kernel filesystems have custom ->open() and ->permission()
> export methods, which nfsd does not respect and it was never meant to be
> used for exporting those filesystems by nfsd.
>
> Therefore, do not allow nfsd to export filesystems with custom ->open()
> or ->permission() methods.
>
> Fixes: b3caba8f7a34a ("pidfs: implement file handle support")
> Fixes: 5222470b2fbb3 ("nsfs: support file handles")
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  fs/nfsd/export.c | 21 +++++++++++++--------
>  1 file changed, 13 insertions(+), 8 deletions(-)
>
> Christian,
>
> I had enough of the stable file handles discussion [1].
>
> This patch which I already suggested [2] on week ago, states a justified
> technical reason why pidfs and nsfs should not be exported by nfsd,
> so let's use this technical reasoning and stop the philosophic discussions
> about what is a stable file handle is please.
>
> Regarding cgroupfs, we can either deal with it later or not - it is not
> a clear but as pidfs and nsfs which absolutely should be fixed
> retroactively in stable kernels.
>
> If you think that cgroupfs could benefit from "exhaustive" file handles [3]
> then we can implement open_by_handle_at(FD_CGROUPFS_ROOT, ... and that
> would classify cgroupfs the same as pidfs and nsfs.
>
> Thanks,
> Amir.
>
> [1] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-0-1a247645cef5@kernel.org/
> [2] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhkaGFtQRzTj2xaf2GJucoAY5CGiyUjB=8YA2zTbOtFvw@mail.gmail.com/
> [3] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-29-1a247645cef5@kernel.org/
>
> diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> index 2a1499f2ad196..232dacac611e9 100644
> --- a/fs/nfsd/export.c
> +++ b/fs/nfsd/export.c
> @@ -405,6 +405,7 @@ static struct svc_export *svc_export_lookup(struct svc_export *);
>  static int check_export(const struct path *path, int *flags, unsigned char *uuid)
>  {
>         struct inode *inode = d_inode(path->dentry);
> +       const struct export_operations *nop = inode->i_sb->s_export_op;
>
>         /*
>          * We currently export only dirs, regular files, and (for v4
> @@ -422,13 +423,12 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
>         if (*flags & NFSEXP_V4ROOT)
>                 *flags |= NFSEXP_READONLY;
>
> -       /* There are two requirements on a filesystem to be exportable.
> -        * 1:  We must be able to identify the filesystem from a number.
> -        *       either a device number (so FS_REQUIRES_DEV needed)
> -        *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
> -        * 2:  We must be able to find an inode from a filehandle.
> -        *       This means that s_export_op must be set.
> -        * 3: We must not currently be on an idmapped mount.
> +       /*
> +        * The requirements for a filesystem to be exportable:
> +        * 1. The filehandle must identify a filesystem by number
> +        * 2. The filehandle must uniquely identify an inode
> +        * 3. The filesystem must not have custom filehandle open/perm methods
> +        * 4. The requested file must not reside on an idmapped mount
>          */
>         if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
>             !(*flags & NFSEXP_FSID) &&
> @@ -437,11 +437,16 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
>                 return -EINVAL;
>         }
>
> -       if (!exportfs_can_decode_fh(inode->i_sb->s_export_op)) {
> +       if (!exportfs_can_decode_fh(nop)) {
>                 dprintk("exp_export: export of invalid fs type.\n");
>                 return -EINVAL;
>         }
>
> +       if (nop->open || nop->permission) {
> +               dprintk("exp_export: export of non-standard fs type.\n");
> +               return -EINVAL;
> +       }
> +
>         if (is_idmapped_mnt(path->mnt)) {
>                 dprintk("exp_export: export of idmapped mounts not yet supported.\n");
>                 return -EINVAL;
> --
> 2.52.0
>

Re: [PATCH] nfsd: do not allow exporting of special kernel filesystems

[NeilBrown]

On Wed, 21 Jan 2026, Amir Goldstein wrote:
> pidfs and nsfs recently gained support for encode/decode of file handles
> via name_to_handle_at(2)/opan_by_handle_at(2).
> 
> These special kernel filesystems have custom ->open() and ->permission()
> export methods, which nfsd does not respect and it was never meant to be
> used for exporting those filesystems by nfsd.
> 
> Therefore, do not allow nfsd to export filesystems with custom ->open()
> or ->permission() methods.
> 
> Fixes: b3caba8f7a34a ("pidfs: implement file handle support")
> Fixes: 5222470b2fbb3 ("nsfs: support file handles")
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  fs/nfsd/export.c | 21 +++++++++++++--------
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> Christian,
> 
> I had enough of the stable file handles discussion [1].
> 
> This patch which I already suggested [2] on week ago, states a justified
> technical reason why pidfs and nsfs should not be exported by nfsd,
> so let's use this technical reasoning and stop the philosophic discussions
> about what is a stable file handle is please.
> 
> Regarding cgroupfs, we can either deal with it later or not - it is not
> a clear but as pidfs and nsfs which absolutely should be fixed
> retroactively in stable kernels.
> 
> If you think that cgroupfs could benefit from "exhaustive" file handles [3]
> then we can implement open_by_handle_at(FD_CGROUPFS_ROOT, ... and that
> would classify cgroupfs the same as pidfs and nsfs.
> 
> Thanks,
> Amir.
> 
> [1] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-0-1a247645cef5@kernel.org/
> [2] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhkaGFtQRzTj2xaf2GJucoAY5CGiyUjB=8YA2zTbOtFvw@mail.gmail.com/
> [3] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-29-1a247645cef5@kernel.org/
> 
> diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> index 2a1499f2ad196..232dacac611e9 100644
> --- a/fs/nfsd/export.c
> +++ b/fs/nfsd/export.c
> @@ -405,6 +405,7 @@ static struct svc_export *svc_export_lookup(struct svc_export *);
>  static int check_export(const struct path *path, int *flags, unsigned char *uuid)
>  {
>  	struct inode *inode = d_inode(path->dentry);
> +	const struct export_operations *nop = inode->i_sb->s_export_op;
>  
>  	/*
>  	 * We currently export only dirs, regular files, and (for v4
> @@ -422,13 +423,12 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
>  	if (*flags & NFSEXP_V4ROOT)
>  		*flags |= NFSEXP_READONLY;
>  
> -	/* There are two requirements on a filesystem to be exportable.
> -	 * 1:  We must be able to identify the filesystem from a number.
> -	 *       either a device number (so FS_REQUIRES_DEV needed)
> -	 *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
> -	 * 2:  We must be able to find an inode from a filehandle.
> -	 *       This means that s_export_op must be set.
> -	 * 3: We must not currently be on an idmapped mount.
> +	/*
> +	 * The requirements for a filesystem to be exportable:
> +	 * 1. The filehandle must identify a filesystem by number
> +	 * 2. The filehandle must uniquely identify an inode
> +	 * 3. The filesystem must not have custom filehandle open/perm methods
> +	 * 4. The requested file must not reside on an idmapped mount
>  	 */
>  	if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
>  	    !(*flags & NFSEXP_FSID) &&
> @@ -437,11 +437,16 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
>  		return -EINVAL;
>  	}
>  
> -	if (!exportfs_can_decode_fh(inode->i_sb->s_export_op)) {
> +	if (!exportfs_can_decode_fh(nop)) {
>  		dprintk("exp_export: export of invalid fs type.\n");
>  		return -EINVAL;
>  	}
>  
> +	if (nop->open || nop->permission) {
> +		dprintk("exp_export: export of non-standard fs type.\n");
> +		return -EINVAL;
> +	}
> +

It is not immediately obvious that this is safe when nop is NULL, but it
is because exportfs_can_decode_fh() checks for that case.  As that is a
static inline a static analyser can easily confirm this.  So it is
probably OK.

"non-standard" is not totally clear.  "special" might be better, or it
might not.  It is only a dprintk so it probably doesn't matter much.

Reviewed-by: NeilBrown <neil@brown.name>

Thanks for posting this.  I think this is a good check to have whether
or not we decide to add a flag.

Thanks,
NeilBrown

>  	if (is_idmapped_mnt(path->mnt)) {
>  		dprintk("exp_export: export of idmapped mounts not yet supported.\n");
>  		return -EINVAL;
> -- 
> 2.52.0
> 
> 
> 

Re: [PATCH] nfsd: do not allow exporting of special kernel filesystems

[Christoph Hellwig]

On Wed, Jan 21, 2026 at 09:50:27AM +0100, Amir Goldstein wrote:
> pidfs and nsfs recently gained support for encode/decode of file handles
> via name_to_handle_at(2)/opan_by_handle_at(2).
> 
> These special kernel filesystems have custom ->open() and ->permission()
> export methods, which nfsd does not respect and it was never meant to be
> used for exporting those filesystems by nfsd.
> 
> Therefore, do not allow nfsd to export filesystems with custom ->open()
> or ->permission() methods.

Yeah, this was added in and not used in the existing export_ops users.

> +	/*
> +	 * The requirements for a filesystem to be exportable:
> +	 * 1. The filehandle must identify a filesystem by number
> +	 * 2. The filehandle must uniquely identify an inode
> +	 * 3. The filesystem must not have custom filehandle open/perm methods
> +	 * 4. The requested file must not reside on an idmapped mount
>  	 */

Please spell out here why ->open and ->permission are not allowed.
Listing what the code does is generally not that useful, while why
it does that provides value.

While looking this I have to say the API documentation for these
methods in exportfs.h is unfortunately completely useless as well.
It doesn't mention the limitation that it's only used by the
non-exportfs code, and also doesn't mention why a file system
would implement or have to implement them :(  The commit messages
adding them are just as bad as well.

Re: [PATCH] nfsd: do not allow exporting of special kernel filesystems

[Amir Goldstein]

On Wed, Jan 21, 2026 at 10:50 AM NeilBrown <neilb@ownmail.net> wrote:
>
> On Wed, 21 Jan 2026, Amir Goldstein wrote:
> > pidfs and nsfs recently gained support for encode/decode of file handles
> > via name_to_handle_at(2)/opan_by_handle_at(2).
> >
> > These special kernel filesystems have custom ->open() and ->permission()
> > export methods, which nfsd does not respect and it was never meant to be
> > used for exporting those filesystems by nfsd.
> >
> > Therefore, do not allow nfsd to export filesystems with custom ->open()
> > or ->permission() methods.
> >
> > Fixes: b3caba8f7a34a ("pidfs: implement file handle support")
> > Fixes: 5222470b2fbb3 ("nsfs: support file handles")
> > Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> > ---
> >  fs/nfsd/export.c | 21 +++++++++++++--------
> >  1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > Christian,
> >
> > I had enough of the stable file handles discussion [1].
> >
> > This patch which I already suggested [2] on week ago, states a justified
> > technical reason why pidfs and nsfs should not be exported by nfsd,
> > so let's use this technical reasoning and stop the philosophic discussions
> > about what is a stable file handle is please.
> >
> > Regarding cgroupfs, we can either deal with it later or not - it is not
> > a clear but as pidfs and nsfs which absolutely should be fixed
> > retroactively in stable kernels.
> >
> > If you think that cgroupfs could benefit from "exhaustive" file handles [3]
> > then we can implement open_by_handle_at(FD_CGROUPFS_ROOT, ... and that
> > would classify cgroupfs the same as pidfs and nsfs.
> >
> > Thanks,
> > Amir.
> >
> > [1] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-0-1a247645cef5@kernel.org/
> > [2] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhkaGFtQRzTj2xaf2GJucoAY5CGiyUjB=8YA2zTbOtFvw@mail.gmail.com/
> > [3] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-29-1a247645cef5@kernel.org/
> >
> > diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> > index 2a1499f2ad196..232dacac611e9 100644
> > --- a/fs/nfsd/export.c
> > +++ b/fs/nfsd/export.c
> > @@ -405,6 +405,7 @@ static struct svc_export *svc_export_lookup(struct svc_export *);
> >  static int check_export(const struct path *path, int *flags, unsigned char *uuid)
> >  {
> >       struct inode *inode = d_inode(path->dentry);
> > +     const struct export_operations *nop = inode->i_sb->s_export_op;
> >
> >       /*
> >        * We currently export only dirs, regular files, and (for v4
> > @@ -422,13 +423,12 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
> >       if (*flags & NFSEXP_V4ROOT)
> >               *flags |= NFSEXP_READONLY;
> >
> > -     /* There are two requirements on a filesystem to be exportable.
> > -      * 1:  We must be able to identify the filesystem from a number.
> > -      *       either a device number (so FS_REQUIRES_DEV needed)
> > -      *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
> > -      * 2:  We must be able to find an inode from a filehandle.
> > -      *       This means that s_export_op must be set.
> > -      * 3: We must not currently be on an idmapped mount.
> > +     /*
> > +      * The requirements for a filesystem to be exportable:
> > +      * 1. The filehandle must identify a filesystem by number
> > +      * 2. The filehandle must uniquely identify an inode
> > +      * 3. The filesystem must not have custom filehandle open/perm methods
> > +      * 4. The requested file must not reside on an idmapped mount
> >        */
> >       if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
> >           !(*flags & NFSEXP_FSID) &&
> > @@ -437,11 +437,16 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
> >               return -EINVAL;
> >       }
> >
> > -     if (!exportfs_can_decode_fh(inode->i_sb->s_export_op)) {
> > +     if (!exportfs_can_decode_fh(nop)) {
> >               dprintk("exp_export: export of invalid fs type.\n");
> >               return -EINVAL;
> >       }
> >
> > +     if (nop->open || nop->permission) {
> > +             dprintk("exp_export: export of non-standard fs type.\n");
> > +             return -EINVAL;
> > +     }
> > +
>
> It is not immediately obvious that this is safe when nop is NULL, but it
> is because exportfs_can_decode_fh() checks for that case.  As that is a
> static inline a static analyser can easily confirm this.  So it is
> probably OK.

Heh, in the RFC patch [1], I had those conditions wrapped in a helper
just below exportfs_can_decode_fh(), so this was more clear, but now
I tried to avoid adding a helper named exportfs_may_nfs_export()... ;)

>
> "non-standard" is not totally clear.  "special" might be better, or it
> might not.  It is only a dprintk so it probably doesn't matter much.
>

In said RFC patch it was using the same dprinkt() ("invalid fs type")
I am not sure that the distinction to two different classes is important.
printing the fstype->name, either with dprintk() or trace point would
be much more valuable IMO.

But Jeff has a patch to convert dprink() to trace point, so I will gladly
leave those decisions for him.

Thanks,
Amir.

[1] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhkaGFtQRzTj2xaf2GJucoAY5CGiyUjB=8YA2zTbOtFvw@mail.gmail.com/

Re: [PATCH] nfsd: do not allow exporting of special kernel filesystems

[Amir Goldstein]

On Wed, Jan 21, 2026 at 11:12 AM Christoph Hellwig <hch@lst.de> wrote:
>
> On Wed, Jan 21, 2026 at 09:50:27AM +0100, Amir Goldstein wrote:
> > pidfs and nsfs recently gained support for encode/decode of file handles
> > via name_to_handle_at(2)/opan_by_handle_at(2).
> >
> > These special kernel filesystems have custom ->open() and ->permission()
> > export methods, which nfsd does not respect and it was never meant to be
> > used for exporting those filesystems by nfsd.
> >
> > Therefore, do not allow nfsd to export filesystems with custom ->open()
> > or ->permission() methods.
>
> Yeah, this was added in and not used in the existing export_ops users.
>

Not used in existing users (nfsd) on purpose to my understanding
That's the point of this patch - to fix this misunderstanding

> > +     /*
> > +      * The requirements for a filesystem to be exportable:
> > +      * 1. The filehandle must identify a filesystem by number
> > +      * 2. The filehandle must uniquely identify an inode
> > +      * 3. The filesystem must not have custom filehandle open/perm methods
> > +      * 4. The requested file must not reside on an idmapped mount
> >        */
>
> Please spell out here why ->open and ->permission are not allowed.
> Listing what the code does is generally not that useful, while why
> it does that provides value.

This is what I had in the RFC patch:
/*
+ * Do not allow exporting to NFS filesystems with custom ->open() and
+ * ->permission() ops, which nfsd does not respect (e.g. pidfs, nsfs).
+ */

I took Chuck's suggestion to rewrite the requirements, but TBH,
I'd rather not touch the existing comment myself at all.
I prefer that Check and Jeff apply a separate patch to rewrite the
documentation if they feel that this is needed or to propose the
phrasing that they prefer.

>
> While looking this I have to say the API documentation for these
> methods in exportfs.h is unfortunately completely useless as well.
> It doesn't mention the limitation that it's only used by the
> non-exportfs code, and also doesn't mention why a file system
> would implement or have to implement them :(  The commit messages
> adding them are just as bad as well.

I will leave that to Christian for a followup patch or to suggest
the phrasing.

Thanks,
Amir.

Re: [PATCH] nfsd: do not allow exporting of special kernel filesystems

[Jeff Layton]

On Wed, 2026-01-21 at 09:50 +0100, Amir Goldstein wrote:
> pidfs and nsfs recently gained support for encode/decode of file handles
> via name_to_handle_at(2)/opan_by_handle_at(2).
> 
> These special kernel filesystems have custom ->open() and ->permission()
> export methods, which nfsd does not respect and it was never meant to be
> used for exporting those filesystems by nfsd.
> 
> Therefore, do not allow nfsd to export filesystems with custom ->open()
> or ->permission() methods.
> 
> Fixes: b3caba8f7a34a ("pidfs: implement file handle support")
> Fixes: 5222470b2fbb3 ("nsfs: support file handles")
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  fs/nfsd/export.c | 21 +++++++++++++--------
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> Christian,
> 
> I had enough of the stable file handles discussion [1].
> 
> This patch which I already suggested [2] on week ago, states a justified
> technical reason why pidfs and nsfs should not be exported by nfsd,
> so let's use this technical reasoning and stop the philosophic discussions
> about what is a stable file handle is please.
> 
> Regarding cgroupfs, we can either deal with it later or not - it is not
> a clear but as pidfs and nsfs which absolutely should be fixed
> retroactively in stable kernels.
> 
> If you think that cgroupfs could benefit from "exhaustive" file handles [3]
> then we can implement open_by_handle_at(FD_CGROUPFS_ROOT, ... and that
> would classify cgroupfs the same as pidfs and nsfs.
> 
> Thanks,
> Amir.
> 
> [1] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-0-1a247645cef5@kernel.org/
> [2] https://lore.kernel.org/linux-fsdevel/CAOQ4uxhkaGFtQRzTj2xaf2GJucoAY5CGiyUjB=8YA2zTbOtFvw@mail.gmail.com/
> [3] https://lore.kernel.org/linux-fsdevel/20250912-work-namespace-v2-29-1a247645cef5@kernel.org/
> 
> diff --git a/fs/nfsd/export.c b/fs/nfsd/export.c
> index 2a1499f2ad196..232dacac611e9 100644
> --- a/fs/nfsd/export.c
> +++ b/fs/nfsd/export.c
> @@ -405,6 +405,7 @@ static struct svc_export *svc_export_lookup(struct svc_export *);
>  static int check_export(const struct path *path, int *flags, unsigned char *uuid)
>  {
>  	struct inode *inode = d_inode(path->dentry);
> +	const struct export_operations *nop = inode->i_sb->s_export_op;
>  
>  	/*
>  	 * We currently export only dirs, regular files, and (for v4
> @@ -422,13 +423,12 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
>  	if (*flags & NFSEXP_V4ROOT)
>  		*flags |= NFSEXP_READONLY;
>  
> -	/* There are two requirements on a filesystem to be exportable.
> -	 * 1:  We must be able to identify the filesystem from a number.
> -	 *       either a device number (so FS_REQUIRES_DEV needed)
> -	 *       or an FSID number (so NFSEXP_FSID or ->uuid is needed).
> -	 * 2:  We must be able to find an inode from a filehandle.
> -	 *       This means that s_export_op must be set.
> -	 * 3: We must not currently be on an idmapped mount.
> +	/*
> +	 * The requirements for a filesystem to be exportable:
> +	 * 1. The filehandle must identify a filesystem by number
> +	 * 2. The filehandle must uniquely identify an inode
> +	 * 3. The filesystem must not have custom filehandle open/perm methods
> +	 * 4. The requested file must not reside on an idmapped mount
>  	 */
>  	if (!(inode->i_sb->s_type->fs_flags & FS_REQUIRES_DEV) &&
>  	    !(*flags & NFSEXP_FSID) &&
> @@ -437,11 +437,16 @@ static int check_export(const struct path *path, int *flags, unsigned char *uuid
>  		return -EINVAL;
>  	}
>  
> -	if (!exportfs_can_decode_fh(inode->i_sb->s_export_op)) {
> +	if (!exportfs_can_decode_fh(nop)) {
>  		dprintk("exp_export: export of invalid fs type.\n");
>  		return -EINVAL;
>  	}
>  
> +	if (nop->open || nop->permission) {
> +		dprintk("exp_export: export of non-standard fs type.\n");
> +		return -EINVAL;
> +	}
> +
>  	if (is_idmapped_mnt(path->mnt)) {
>  		dprintk("exp_export: export of idmapped mounts not yet supported.\n");
>  		return -EINVAL;

Seems reasonable, though I agree with HCH that you should explain why
we're excluding these in the "requirements" above.

Reviewed-by: Jeff Layton <jlayton@kernel.org>

Re: [PATCH] nfsd: do not allow exporting of special kernel filesystems

[Christoph Hellwig]

On Wed, Jan 21, 2026 at 11:24:47AM +0100, Amir Goldstein wrote:
> > It is not immediately obvious that this is safe when nop is NULL, but it
> > is because exportfs_can_decode_fh() checks for that case.  As that is a
> > static inline a static analyser can easily confirm this.  So it is
> > probably OK.
> 
> Heh, in the RFC patch [1], I had those conditions wrapped in a helper
> just below exportfs_can_decode_fh(), so this was more clear, but now
> I tried to avoid adding a helper named exportfs_may_nfs_export()... ;)

Please drop the nfs - exportfs is a generic layer, and not tried to
nfs, even if that's currently the only user.

Re: [PATCH] nfsd: do not allow exporting of special kernel filesystems

[Christoph Hellwig]

On Wed, Jan 21, 2026 at 11:35:11AM +0100, Amir Goldstein wrote:
> On Wed, Jan 21, 2026 at 11:12 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > On Wed, Jan 21, 2026 at 09:50:27AM +0100, Amir Goldstein wrote:
> > > pidfs and nsfs recently gained support for encode/decode of file handles
> > > via name_to_handle_at(2)/opan_by_handle_at(2).
> > >
> > > These special kernel filesystems have custom ->open() and ->permission()
> > > export methods, which nfsd does not respect and it was never meant to be
> > > used for exporting those filesystems by nfsd.
> > >
> > > Therefore, do not allow nfsd to export filesystems with custom ->open()
> > > or ->permission() methods.
> >
> > Yeah, this was added in and not used in the existing export_ops users.
> >
> 
> Not used in existing users (nfsd) on purpose to my understanding
> That's the point of this patch - to fix this misunderstanding

Well, I've dug through the documentation and commits that added it,
and there's absolutely nothing explaining the intent unfortunately.

> >
> > Please spell out here why ->open and ->permission are not allowed.
> > Listing what the code does is generally not that useful, while why
> > it does that provides value.
> 
> This is what I had in the RFC patch:
> /*
> + * Do not allow exporting to NFS filesystems with custom ->open() and
> + * ->permission() ops, which nfsd does not respect (e.g. pidfs, nsfs).
> + */
> 
> I took Chuck's suggestion to rewrite the requirements, but TBH,
> I'd rather not touch the existing comment myself at all.
> I prefer that Check and Jeff apply a separate patch to rewrite the
> documentation if they feel that this is needed or to propose the
> phrasing that they prefer.

I don't really care who writes the documentation, but if we reject
based on the presence of the methods we really need to document
the why.  

> > While looking this I have to say the API documentation for these
> > methods in exportfs.h is unfortunately completely useless as well.
> > It doesn't mention the limitation that it's only used by the
> > non-exportfs code, and also doesn't mention why a file system
> > would implement or have to implement them :(  The commit messages
> > adding them are just as bad as well.
> 
> I will leave that to Christian for a followup patch or to suggest
> the phrasing.

Yes, I think we really need a braindump from Christian here.  If
you don't want to add that to the documentation I'll find some
time to include it into a revision, because documenting these
kinds of things is really essential.  We're already confused only
2 years after this was added, and it's only going to get worse.