[PATCH 0/2] ovl: allow O_PATH file descriptor when specifying layers

[PATCH 0/2] ovl: allow O_PATH file descriptor when specifying layers

[Christian Brauner]

Allow overlayfs to use O_PATH file descriptors when specifying layers.
Userspace must currently use non-O_PATH file desriptors which is often
pointless especially if the file descriptors have been created via
open_tree(OPEN_TREE_CLONE). This has been a frequent request and came up
again in [1].

Link: https://lore.kernel.org/r/fd8f6574-f737-4743-b220-79c815ee1554@mbaynton.com [1]

Signed-off-by: Christian Brauner <brauner@kernel.org>
---
Christian Brauner (2):
      fs: support O_PATH fds with FSCONFIG_SET_FD
      selftests/overlayfs: test specifying layers as O_PATH file descriptors

 fs/fs_parser.c                                     | 12 ++--
 fs/fsopen.c                                        |  7 ++-
 fs/overlayfs/params.c                              | 10 ++--
 include/linux/fs_context.h                         |  1 +
 include/linux/fs_parser.h                          |  6 +-
 .../filesystems/overlayfs/set_layers_via_fds.c     | 65 ++++++++++++++++++++++
 6 files changed, 87 insertions(+), 14 deletions(-)
---
base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b
change-id: 20250207-work-overlayfs-38fb9156d4c4

[PATCH 1/2] fs: support O_PATH fds with FSCONFIG_SET_FD

[Christian Brauner]

Let FSCONFIG_SET_FD handle O_PATH file descriptors. This is particularly
useful in the context of overlayfs where layers can be specified via
file descriptors instead of paths. But userspace must currently use
non-O_PATH file desriptors which is often pointless especially if
the file descriptors have been created via open_tree(OPEN_TREE_CLONE).

Signed-off-by: Christian Brauner <brauner@kernel.org>
---
 fs/fs_parser.c             | 12 +++++++-----
 fs/fsopen.c                |  7 +++++--
 fs/overlayfs/params.c      | 10 ++++++----
 include/linux/fs_context.h |  1 +
 include/linux/fs_parser.h  |  6 +++---
 5 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/fs/fs_parser.c b/fs/fs_parser.c
index e635a81e17d9..35aaea224007 100644
--- a/fs/fs_parser.c
+++ b/fs/fs_parser.c
@@ -310,15 +310,17 @@ int fs_param_is_fd(struct p_log *log, const struct fs_parameter_spec *p,
 }
 EXPORT_SYMBOL(fs_param_is_fd);
 
-int fs_param_is_file_or_string(struct p_log *log,
-			       const struct fs_parameter_spec *p,
-			       struct fs_parameter *param,
-			       struct fs_parse_result *result)
+int fs_param_is_raw_file_or_string(struct p_log *log,
+				   const struct fs_parameter_spec *p,
+				   struct fs_parameter *param,
+				   struct fs_parse_result *result)
 {
 	switch (param->type) {
 	case fs_value_is_string:
 		return fs_param_is_string(log, p, param, result);
 	case fs_value_is_file:
+		fallthrough;
+	case fs_value_is_raw_file:
 		result->uint_32 = param->dirfd;
 		if (result->uint_32 <= INT_MAX)
 			return 0;
@@ -328,7 +330,7 @@ int fs_param_is_file_or_string(struct p_log *log,
 	}
 	return fs_param_bad_value(log, param);
 }
-EXPORT_SYMBOL(fs_param_is_file_or_string);
+EXPORT_SYMBOL(fs_param_is_raw_file_or_string);
 
 int fs_param_is_uid(struct p_log *log, const struct fs_parameter_spec *p,
 		    struct fs_parameter *param, struct fs_parse_result *result)
diff --git a/fs/fsopen.c b/fs/fsopen.c
index 094a7f510edf..3b5fc9f1f774 100644
--- a/fs/fsopen.c
+++ b/fs/fsopen.c
@@ -451,11 +451,14 @@ SYSCALL_DEFINE5(fsconfig,
 		param.size = strlen(param.name->name);
 		break;
 	case FSCONFIG_SET_FD:
-		param.type = fs_value_is_file;
 		ret = -EBADF;
-		param.file = fget(aux);
+		param.file = fget_raw(aux);
 		if (!param.file)
 			goto out_key;
+		if (param.file->f_mode & FMODE_PATH)
+			param.type = fs_value_is_raw_file;
+		else
+			param.type = fs_value_is_file;
 		param.dirfd = aux;
 		break;
 	default:
diff --git a/fs/overlayfs/params.c b/fs/overlayfs/params.c
index 1115c22deca0..846afa6081a5 100644
--- a/fs/overlayfs/params.c
+++ b/fs/overlayfs/params.c
@@ -141,10 +141,10 @@ static int ovl_verity_mode_def(void)
 
 const struct fs_parameter_spec ovl_parameter_spec[] = {
 	fsparam_string_empty("lowerdir",    Opt_lowerdir),
-	fsparam_file_or_string("lowerdir+", Opt_lowerdir_add),
-	fsparam_file_or_string("datadir+",  Opt_datadir_add),
-	fsparam_file_or_string("upperdir",  Opt_upperdir),
-	fsparam_file_or_string("workdir",   Opt_workdir),
+	fsparam_raw_file_or_string("lowerdir+", Opt_lowerdir_add),
+	fsparam_raw_file_or_string("datadir+",  Opt_datadir_add),
+	fsparam_raw_file_or_string("upperdir",  Opt_upperdir),
+	fsparam_raw_file_or_string("workdir",   Opt_workdir),
 	fsparam_flag("default_permissions", Opt_default_permissions),
 	fsparam_enum("redirect_dir",        Opt_redirect_dir, ovl_parameter_redirect_dir),
 	fsparam_enum("index",               Opt_index, ovl_parameter_bool),
@@ -438,6 +438,8 @@ static int ovl_parse_layer(struct fs_context *fc, struct fs_parameter *param,
 			return err;
 		err = ovl_do_parse_layer(fc, param->string, &layer_path, layer);
 		break;
+	case fs_value_is_raw_file:
+		fallthrough;
 	case fs_value_is_file: {
 		char *buf __free(kfree);
 		char *layer_name;
diff --git a/include/linux/fs_context.h b/include/linux/fs_context.h
index 4b4bfef6f053..4ba18211046e 100644
--- a/include/linux/fs_context.h
+++ b/include/linux/fs_context.h
@@ -55,6 +55,7 @@ enum fs_value_type {
 	fs_value_is_blob,		/* Value is a binary blob */
 	fs_value_is_filename,		/* Value is a filename* + dirfd */
 	fs_value_is_file,		/* Value is a file* */
+	fs_value_is_raw_file,		/* Value is an O_PATH/FMODE_PATH file* */
 };
 
 /*
diff --git a/include/linux/fs_parser.h b/include/linux/fs_parser.h
index 53e566efd5fd..77d5d3c78d39 100644
--- a/include/linux/fs_parser.h
+++ b/include/linux/fs_parser.h
@@ -29,7 +29,7 @@ typedef int fs_param_type(struct p_log *,
 fs_param_type fs_param_is_bool, fs_param_is_u32, fs_param_is_s32, fs_param_is_u64,
 	fs_param_is_enum, fs_param_is_string, fs_param_is_blob, fs_param_is_blockdev,
 	fs_param_is_path, fs_param_is_fd, fs_param_is_uid, fs_param_is_gid,
-	fs_param_is_file_or_string;
+	fs_param_is_raw_file_or_string;
 
 /*
  * Specification of the type of value a parameter wants.
@@ -136,8 +136,8 @@ static inline bool fs_validate_description(const char *name,
 #define fsparam_bdev(NAME, OPT)	__fsparam(fs_param_is_blockdev, NAME, OPT, 0, NULL)
 #define fsparam_path(NAME, OPT)	__fsparam(fs_param_is_path, NAME, OPT, 0, NULL)
 #define fsparam_fd(NAME, OPT)	__fsparam(fs_param_is_fd, NAME, OPT, 0, NULL)
-#define fsparam_file_or_string(NAME, OPT) \
-				__fsparam(fs_param_is_file_or_string, NAME, OPT, 0, NULL)
+#define fsparam_raw_file_or_string(NAME, OPT) \
+				__fsparam(fs_param_is_raw_file_or_string, NAME, OPT, 0, NULL)
 #define fsparam_uid(NAME, OPT) __fsparam(fs_param_is_uid, NAME, OPT, 0, NULL)
 #define fsparam_gid(NAME, OPT) __fsparam(fs_param_is_gid, NAME, OPT, 0, NULL)
 

-- 
2.47.2

[PATCH 2/2] selftests/overlayfs: test specifying layers as O_PATH file descriptors

[Christian Brauner]

Verify that userspace can specify layers via O_PATH file descriptors.

Signed-off-by: Christian Brauner <brauner@kernel.org>
---
 .../filesystems/overlayfs/set_layers_via_fds.c     | 65 ++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff --git a/tools/testing/selftests/filesystems/overlayfs/set_layers_via_fds.c b/tools/testing/selftests/filesystems/overlayfs/set_layers_via_fds.c
index 1d0ae785a667..e693e4102d22 100644
--- a/tools/testing/selftests/filesystems/overlayfs/set_layers_via_fds.c
+++ b/tools/testing/selftests/filesystems/overlayfs/set_layers_via_fds.c
@@ -214,4 +214,69 @@ TEST_F(set_layers_via_fds, set_500_layers_via_fds)
 	ASSERT_EQ(close(fd_overlay), 0);
 }
 
+TEST_F(set_layers_via_fds, set_500_layers_via_opath_fds)
+{
+	int fd_context, fd_tmpfs, fd_overlay, fd_work, fd_upper, fd_lower;
+	int layer_fds[500] = { [0 ... 499] = -EBADF };
+
+	ASSERT_EQ(unshare(CLONE_NEWNS), 0);
+	ASSERT_EQ(sys_mount(NULL, "/", NULL, MS_SLAVE | MS_REC, NULL), 0);
+
+	fd_context = sys_fsopen("tmpfs", 0);
+	ASSERT_GE(fd_context, 0);
+
+	ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_CMD_CREATE, NULL, NULL, 0), 0);
+	fd_tmpfs = sys_fsmount(fd_context, 0, 0);
+	ASSERT_GE(fd_tmpfs, 0);
+	ASSERT_EQ(close(fd_context), 0);
+
+	for (int i = 0; i < ARRAY_SIZE(layer_fds); i++) {
+		char path[100];
+
+		sprintf(path, "l%d", i);
+		ASSERT_EQ(mkdirat(fd_tmpfs, path, 0755), 0);
+		layer_fds[i] = openat(fd_tmpfs, path, O_DIRECTORY | O_PATH);
+		ASSERT_GE(layer_fds[i], 0);
+	}
+
+	ASSERT_EQ(mkdirat(fd_tmpfs, "w", 0755), 0);
+	fd_work = openat(fd_tmpfs, "w", O_DIRECTORY | O_PATH);
+	ASSERT_GE(fd_work, 0);
+
+	ASSERT_EQ(mkdirat(fd_tmpfs, "u", 0755), 0);
+	fd_upper = openat(fd_tmpfs, "u", O_DIRECTORY | O_PATH);
+	ASSERT_GE(fd_upper, 0);
+
+	ASSERT_EQ(mkdirat(fd_tmpfs, "l501", 0755), 0);
+	fd_lower = openat(fd_tmpfs, "l501", O_DIRECTORY | O_PATH);
+	ASSERT_GE(fd_lower, 0);
+
+	ASSERT_EQ(sys_move_mount(fd_tmpfs, "", -EBADF, "/tmp", MOVE_MOUNT_F_EMPTY_PATH), 0);
+	ASSERT_EQ(close(fd_tmpfs), 0);
+
+	fd_context = sys_fsopen("overlay", 0);
+	ASSERT_GE(fd_context, 0);
+
+	ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_SET_FD, "workdir",   NULL, fd_work), 0);
+	ASSERT_EQ(close(fd_work), 0);
+
+	ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_SET_FD, "upperdir",  NULL, fd_upper), 0);
+	ASSERT_EQ(close(fd_upper), 0);
+
+	for (int i = 0; i < ARRAY_SIZE(layer_fds); i++) {
+		ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_SET_FD, "lowerdir+", NULL, layer_fds[i]), 0);
+		ASSERT_EQ(close(layer_fds[i]), 0);
+	}
+
+	ASSERT_NE(sys_fsconfig(fd_context, FSCONFIG_SET_FD, "lowerdir+", NULL, fd_lower), 0);
+	ASSERT_EQ(close(fd_lower), 0);
+
+	ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_CMD_CREATE, NULL, NULL, 0), 0);
+
+	fd_overlay = sys_fsmount(fd_context, 0, 0);
+	ASSERT_GE(fd_overlay, 0);
+	ASSERT_EQ(close(fd_context), 0);
+	ASSERT_EQ(close(fd_overlay), 0);
+}
+
 TEST_HARNESS_MAIN

-- 
2.47.2

Re: [PATCH 1/2] fs: support O_PATH fds with FSCONFIG_SET_FD

[Amir Goldstein]

On Fri, Feb 7, 2025 at 4:46 PM Christian Brauner <brauner@kernel.org> wrote:
>
> Let FSCONFIG_SET_FD handle O_PATH file descriptors. This is particularly
> useful in the context of overlayfs where layers can be specified via
> file descriptors instead of paths. But userspace must currently use
> non-O_PATH file desriptors which is often pointless especially if
> the file descriptors have been created via open_tree(OPEN_TREE_CLONE).
>

Shall we?
Fixes: a08557d19ef41 ("ovl: specify layers via file descriptors")

I think that was the intention of the API and we are not far enough to fix
it in 6.12.y.


> Signed-off-by: Christian Brauner <brauner@kernel.org>
> ---
>  fs/fs_parser.c             | 12 +++++++-----
>  fs/fsopen.c                |  7 +++++--
>  fs/overlayfs/params.c      | 10 ++++++----
>  include/linux/fs_context.h |  1 +
>  include/linux/fs_parser.h  |  6 +++---
>  5 files changed, 22 insertions(+), 14 deletions(-)
>
> diff --git a/fs/fs_parser.c b/fs/fs_parser.c
> index e635a81e17d9..35aaea224007 100644
> --- a/fs/fs_parser.c
> +++ b/fs/fs_parser.c
> @@ -310,15 +310,17 @@ int fs_param_is_fd(struct p_log *log, const struct fs_parameter_spec *p,
>  }
>  EXPORT_SYMBOL(fs_param_is_fd);
>
> -int fs_param_is_file_or_string(struct p_log *log,
> -                              const struct fs_parameter_spec *p,
> -                              struct fs_parameter *param,
> -                              struct fs_parse_result *result)
> +int fs_param_is_raw_file_or_string(struct p_log *log,

Besides being too long of a helper name I do not think
that it correctly reflects the spirit of the question.

The arguments for overlayfs upperdir/workdir/lowerdir+/datadir+
need to be *a path*, either a path string, or an O_PATH fd and
maybe later on also dirfd+name.

I imagine that if other filesystems would want to use this parser
helper they would need it for the same purpose.

Can we maybe come up with a name that better reflects that
intention?

> +                                  const struct fs_parameter_spec *p,
> +                                  struct fs_parameter *param,
> +                                  struct fs_parse_result *result)
>  {
>         switch (param->type) {
>         case fs_value_is_string:
>                 return fs_param_is_string(log, p, param, result);
>         case fs_value_is_file:
> +               fallthrough;
> +       case fs_value_is_raw_file:
>                 result->uint_32 = param->dirfd;
>                 if (result->uint_32 <= INT_MAX)
>                         return 0;
> @@ -328,7 +330,7 @@ int fs_param_is_file_or_string(struct p_log *log,
>         }
>         return fs_param_bad_value(log, param);
>  }
> -EXPORT_SYMBOL(fs_param_is_file_or_string);
> +EXPORT_SYMBOL(fs_param_is_raw_file_or_string);
>
>  int fs_param_is_uid(struct p_log *log, const struct fs_parameter_spec *p,
>                     struct fs_parameter *param, struct fs_parse_result *result)
> diff --git a/fs/fsopen.c b/fs/fsopen.c
> index 094a7f510edf..3b5fc9f1f774 100644
> --- a/fs/fsopen.c
> +++ b/fs/fsopen.c
> @@ -451,11 +451,14 @@ SYSCALL_DEFINE5(fsconfig,
>                 param.size = strlen(param.name->name);
>                 break;
>         case FSCONFIG_SET_FD:
> -               param.type = fs_value_is_file;
>                 ret = -EBADF;
> -               param.file = fget(aux);
> +               param.file = fget_raw(aux);
>                 if (!param.file)
>                         goto out_key;
> +               if (param.file->f_mode & FMODE_PATH)
> +                       param.type = fs_value_is_raw_file;
> +               else
> +                       param.type = fs_value_is_file;
>                 param.dirfd = aux;

Here it even shouts more to me that the distinction is not needed.

If the parameter would be defined as
fsparam_path_description("workdir",   Opt_workdir),
and we set param.type = fs_value_is_path_fd;
unconditional to f_mode & FMODE_PATH, because we
do not care if fd is O_PATH or not for the purpose of this parameter
we only care that the parameter *can* be resolved to a path
and *how* to resolve it to a path, and the answer to those questions
does not change depending on _mode & FMODE_PATH.

I admit that that's a very long rant about a mostly meaningless nuance,
and I was also not very involved in the development of the new mount API
so there may be things about it that I don't understand, so feel free to
dismiss this rant and add my Ack if you do not share my concerns.

Thanks,
Amir.

Re: [PATCH 2/2] selftests/overlayfs: test specifying layers as O_PATH file descriptors

[Amir Goldstein]

On Fri, Feb 7, 2025 at 4:46 PM Christian Brauner <brauner@kernel.org> wrote:
>
> Verify that userspace can specify layers via O_PATH file descriptors.
>
> Signed-off-by: Christian Brauner <brauner@kernel.org>

Reviewed-by: Amir Goldstein <amir73il@gmail.com>

> ---
>  .../filesystems/overlayfs/set_layers_via_fds.c     | 65 ++++++++++++++++++++++
>  1 file changed, 65 insertions(+)
>
> diff --git a/tools/testing/selftests/filesystems/overlayfs/set_layers_via_fds.c b/tools/testing/selftests/filesystems/overlayfs/set_layers_via_fds.c
> index 1d0ae785a667..e693e4102d22 100644
> --- a/tools/testing/selftests/filesystems/overlayfs/set_layers_via_fds.c
> +++ b/tools/testing/selftests/filesystems/overlayfs/set_layers_via_fds.c
> @@ -214,4 +214,69 @@ TEST_F(set_layers_via_fds, set_500_layers_via_fds)
>         ASSERT_EQ(close(fd_overlay), 0);
>  }
>
> +TEST_F(set_layers_via_fds, set_500_layers_via_opath_fds)
> +{
> +       int fd_context, fd_tmpfs, fd_overlay, fd_work, fd_upper, fd_lower;
> +       int layer_fds[500] = { [0 ... 499] = -EBADF };
> +
> +       ASSERT_EQ(unshare(CLONE_NEWNS), 0);
> +       ASSERT_EQ(sys_mount(NULL, "/", NULL, MS_SLAVE | MS_REC, NULL), 0);
> +
> +       fd_context = sys_fsopen("tmpfs", 0);
> +       ASSERT_GE(fd_context, 0);
> +
> +       ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_CMD_CREATE, NULL, NULL, 0), 0);
> +       fd_tmpfs = sys_fsmount(fd_context, 0, 0);
> +       ASSERT_GE(fd_tmpfs, 0);
> +       ASSERT_EQ(close(fd_context), 0);
> +
> +       for (int i = 0; i < ARRAY_SIZE(layer_fds); i++) {
> +               char path[100];
> +
> +               sprintf(path, "l%d", i);
> +               ASSERT_EQ(mkdirat(fd_tmpfs, path, 0755), 0);
> +               layer_fds[i] = openat(fd_tmpfs, path, O_DIRECTORY | O_PATH);
> +               ASSERT_GE(layer_fds[i], 0);
> +       }
> +
> +       ASSERT_EQ(mkdirat(fd_tmpfs, "w", 0755), 0);
> +       fd_work = openat(fd_tmpfs, "w", O_DIRECTORY | O_PATH);
> +       ASSERT_GE(fd_work, 0);
> +
> +       ASSERT_EQ(mkdirat(fd_tmpfs, "u", 0755), 0);
> +       fd_upper = openat(fd_tmpfs, "u", O_DIRECTORY | O_PATH);
> +       ASSERT_GE(fd_upper, 0);
> +
> +       ASSERT_EQ(mkdirat(fd_tmpfs, "l501", 0755), 0);
> +       fd_lower = openat(fd_tmpfs, "l501", O_DIRECTORY | O_PATH);
> +       ASSERT_GE(fd_lower, 0);
> +
> +       ASSERT_EQ(sys_move_mount(fd_tmpfs, "", -EBADF, "/tmp", MOVE_MOUNT_F_EMPTY_PATH), 0);
> +       ASSERT_EQ(close(fd_tmpfs), 0);
> +
> +       fd_context = sys_fsopen("overlay", 0);
> +       ASSERT_GE(fd_context, 0);
> +
> +       ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_SET_FD, "workdir",   NULL, fd_work), 0);
> +       ASSERT_EQ(close(fd_work), 0);
> +
> +       ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_SET_FD, "upperdir",  NULL, fd_upper), 0);
> +       ASSERT_EQ(close(fd_upper), 0);
> +
> +       for (int i = 0; i < ARRAY_SIZE(layer_fds); i++) {
> +               ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_SET_FD, "lowerdir+", NULL, layer_fds[i]), 0);
> +               ASSERT_EQ(close(layer_fds[i]), 0);
> +       }
> +
> +       ASSERT_NE(sys_fsconfig(fd_context, FSCONFIG_SET_FD, "lowerdir+", NULL, fd_lower), 0);
> +       ASSERT_EQ(close(fd_lower), 0);
> +
> +       ASSERT_EQ(sys_fsconfig(fd_context, FSCONFIG_CMD_CREATE, NULL, NULL, 0), 0);
> +
> +       fd_overlay = sys_fsmount(fd_context, 0, 0);
> +       ASSERT_GE(fd_overlay, 0);
> +       ASSERT_EQ(close(fd_context), 0);
> +       ASSERT_EQ(close(fd_overlay), 0);
> +}
> +
>  TEST_HARNESS_MAIN
>
> --
> 2.47.2
>

Re: [PATCH 1/2] fs: support O_PATH fds with FSCONFIG_SET_FD

[Amir Goldstein]

On Fri, Feb 7, 2025 at 6:39 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Fri, Feb 7, 2025 at 4:46 PM Christian Brauner <brauner@kernel.org> wrote:
> >
> > Let FSCONFIG_SET_FD handle O_PATH file descriptors. This is particularly
> > useful in the context of overlayfs where layers can be specified via
> > file descriptors instead of paths. But userspace must currently use
> > non-O_PATH file desriptors which is often pointless especially if
> > the file descriptors have been created via open_tree(OPEN_TREE_CLONE).
> >
>
> Shall we?
> Fixes: a08557d19ef41 ("ovl: specify layers via file descriptors")
>
> I think that was the intention of the API and we are not far enough to fix
> it in 6.12.y.
>

Oh it's not in 6.12. it's in 6.13, so less important to backport I guess.

Thanks,
Amir.

>
> > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > ---
> >  fs/fs_parser.c             | 12 +++++++-----
> >  fs/fsopen.c                |  7 +++++--
> >  fs/overlayfs/params.c      | 10 ++++++----
> >  include/linux/fs_context.h |  1 +
> >  include/linux/fs_parser.h  |  6 +++---
> >  5 files changed, 22 insertions(+), 14 deletions(-)
> >
> > diff --git a/fs/fs_parser.c b/fs/fs_parser.c
> > index e635a81e17d9..35aaea224007 100644
> > --- a/fs/fs_parser.c
> > +++ b/fs/fs_parser.c
> > @@ -310,15 +310,17 @@ int fs_param_is_fd(struct p_log *log, const struct fs_parameter_spec *p,
> >  }
> >  EXPORT_SYMBOL(fs_param_is_fd);
> >
> > -int fs_param_is_file_or_string(struct p_log *log,
> > -                              const struct fs_parameter_spec *p,
> > -                              struct fs_parameter *param,
> > -                              struct fs_parse_result *result)
> > +int fs_param_is_raw_file_or_string(struct p_log *log,
>
> Besides being too long of a helper name I do not think
> that it correctly reflects the spirit of the question.
>
> The arguments for overlayfs upperdir/workdir/lowerdir+/datadir+
> need to be *a path*, either a path string, or an O_PATH fd and
> maybe later on also dirfd+name.
>
> I imagine that if other filesystems would want to use this parser
> helper they would need it for the same purpose.
>
> Can we maybe come up with a name that better reflects that
> intention?
>
> > +                                  const struct fs_parameter_spec *p,
> > +                                  struct fs_parameter *param,
> > +                                  struct fs_parse_result *result)
> >  {
> >         switch (param->type) {
> >         case fs_value_is_string:
> >                 return fs_param_is_string(log, p, param, result);
> >         case fs_value_is_file:
> > +               fallthrough;
> > +       case fs_value_is_raw_file:
> >                 result->uint_32 = param->dirfd;
> >                 if (result->uint_32 <= INT_MAX)
> >                         return 0;
> > @@ -328,7 +330,7 @@ int fs_param_is_file_or_string(struct p_log *log,
> >         }
> >         return fs_param_bad_value(log, param);
> >  }
> > -EXPORT_SYMBOL(fs_param_is_file_or_string);
> > +EXPORT_SYMBOL(fs_param_is_raw_file_or_string);
> >
> >  int fs_param_is_uid(struct p_log *log, const struct fs_parameter_spec *p,
> >                     struct fs_parameter *param, struct fs_parse_result *result)
> > diff --git a/fs/fsopen.c b/fs/fsopen.c
> > index 094a7f510edf..3b5fc9f1f774 100644
> > --- a/fs/fsopen.c
> > +++ b/fs/fsopen.c
> > @@ -451,11 +451,14 @@ SYSCALL_DEFINE5(fsconfig,
> >                 param.size = strlen(param.name->name);
> >                 break;
> >         case FSCONFIG_SET_FD:
> > -               param.type = fs_value_is_file;
> >                 ret = -EBADF;
> > -               param.file = fget(aux);
> > +               param.file = fget_raw(aux);
> >                 if (!param.file)
> >                         goto out_key;
> > +               if (param.file->f_mode & FMODE_PATH)
> > +                       param.type = fs_value_is_raw_file;
> > +               else
> > +                       param.type = fs_value_is_file;
> >                 param.dirfd = aux;
>
> Here it even shouts more to me that the distinction is not needed.
>
> If the parameter would be defined as
> fsparam_path_description("workdir",   Opt_workdir),
> and we set param.type = fs_value_is_path_fd;
> unconditional to f_mode & FMODE_PATH, because we
> do not care if fd is O_PATH or not for the purpose of this parameter
> we only care that the parameter *can* be resolved to a path
> and *how* to resolve it to a path, and the answer to those questions
> does not change depending on _mode & FMODE_PATH.
>
> I admit that that's a very long rant about a mostly meaningless nuance,
> and I was also not very involved in the development of the new mount API
> so there may be things about it that I don't understand, so feel free to
> dismiss this rant and add my Ack if you do not share my concerns.
>
> Thanks,
> Amir.

Re: [PATCH 1/2] fs: support O_PATH fds with FSCONFIG_SET_FD

[Christian Brauner]

On Fri, Feb 07, 2025 at 07:09:44PM +0100, Amir Goldstein wrote:
> On Fri, Feb 7, 2025 at 6:39 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Fri, Feb 7, 2025 at 4:46 PM Christian Brauner <brauner@kernel.org> wrote:
> > >
> > > Let FSCONFIG_SET_FD handle O_PATH file descriptors. This is particularly
> > > useful in the context of overlayfs where layers can be specified via
> > > file descriptors instead of paths. But userspace must currently use
> > > non-O_PATH file desriptors which is often pointless especially if
> > > the file descriptors have been created via open_tree(OPEN_TREE_CLONE).
> > >
> >
> > Shall we?
> > Fixes: a08557d19ef41 ("ovl: specify layers via file descriptors")
> >
> > I think that was the intention of the API and we are not far enough to fix
> > it in 6.12.y.
> >
> 
> Oh it's not in 6.12. it's in 6.13, so less important to backport I guess.
> 
> Thanks,
> Amir.
> 
> >
> > > Signed-off-by: Christian Brauner <brauner@kernel.org>
> > > ---
> > >  fs/fs_parser.c             | 12 +++++++-----
> > >  fs/fsopen.c                |  7 +++++--
> > >  fs/overlayfs/params.c      | 10 ++++++----
> > >  include/linux/fs_context.h |  1 +
> > >  include/linux/fs_parser.h  |  6 +++---
> > >  5 files changed, 22 insertions(+), 14 deletions(-)
> > >
> > > diff --git a/fs/fs_parser.c b/fs/fs_parser.c
> > > index e635a81e17d9..35aaea224007 100644
> > > --- a/fs/fs_parser.c
> > > +++ b/fs/fs_parser.c
> > > @@ -310,15 +310,17 @@ int fs_param_is_fd(struct p_log *log, const struct fs_parameter_spec *p,
> > >  }
> > >  EXPORT_SYMBOL(fs_param_is_fd);
> > >
> > > -int fs_param_is_file_or_string(struct p_log *log,
> > > -                              const struct fs_parameter_spec *p,
> > > -                              struct fs_parameter *param,
> > > -                              struct fs_parse_result *result)
> > > +int fs_param_is_raw_file_or_string(struct p_log *log,
> >
> > Besides being too long of a helper name I do not think
> > that it correctly reflects the spirit of the question.
> >
> > The arguments for overlayfs upperdir/workdir/lowerdir+/datadir+
> > need to be *a path*, either a path string, or an O_PATH fd and
> > maybe later on also dirfd+name.
> >
> > I imagine that if other filesystems would want to use this parser
> > helper they would need it for the same purpose.
> >
> > Can we maybe come up with a name that better reflects that
> > intention?
> >
> > > +                                  const struct fs_parameter_spec *p,
> > > +                                  struct fs_parameter *param,
> > > +                                  struct fs_parse_result *result)
> > >  {
> > >         switch (param->type) {
> > >         case fs_value_is_string:
> > >                 return fs_param_is_string(log, p, param, result);
> > >         case fs_value_is_file:
> > > +               fallthrough;
> > > +       case fs_value_is_raw_file:
> > >                 result->uint_32 = param->dirfd;
> > >                 if (result->uint_32 <= INT_MAX)
> > >                         return 0;
> > > @@ -328,7 +330,7 @@ int fs_param_is_file_or_string(struct p_log *log,
> > >         }
> > >         return fs_param_bad_value(log, param);
> > >  }
> > > -EXPORT_SYMBOL(fs_param_is_file_or_string);
> > > +EXPORT_SYMBOL(fs_param_is_raw_file_or_string);
> > >
> > >  int fs_param_is_uid(struct p_log *log, const struct fs_parameter_spec *p,
> > >                     struct fs_parameter *param, struct fs_parse_result *result)
> > > diff --git a/fs/fsopen.c b/fs/fsopen.c
> > > index 094a7f510edf..3b5fc9f1f774 100644
> > > --- a/fs/fsopen.c
> > > +++ b/fs/fsopen.c
> > > @@ -451,11 +451,14 @@ SYSCALL_DEFINE5(fsconfig,
> > >                 param.size = strlen(param.name->name);
> > >                 break;
> > >         case FSCONFIG_SET_FD:
> > > -               param.type = fs_value_is_file;
> > >                 ret = -EBADF;
> > > -               param.file = fget(aux);
> > > +               param.file = fget_raw(aux);
> > >                 if (!param.file)
> > >                         goto out_key;
> > > +               if (param.file->f_mode & FMODE_PATH)
> > > +                       param.type = fs_value_is_raw_file;
> > > +               else
> > > +                       param.type = fs_value_is_file;
> > >                 param.dirfd = aux;
> >
> > Here it even shouts more to me that the distinction is not needed.
> >
> > If the parameter would be defined as
> > fsparam_path_description("workdir",   Opt_workdir),
> > and we set param.type = fs_value_is_path_fd;
> > unconditional to f_mode & FMODE_PATH, because we
> > do not care if fd is O_PATH or not for the purpose of this parameter
> > we only care that the parameter *can* be resolved to a path
> > and *how* to resolve it to a path, and the answer to those questions
> > does not change depending on _mode & FMODE_PATH.
> >
> > I admit that that's a very long rant about a mostly meaningless nuance,
> > and I was also not very involved in the development of the new mount API
> > so there may be things about it that I don't understand, so feel free to
> > dismiss this rant and add my Ack if you do not share my concerns.

So the reason I originally carried this distinction into the api was
that autofs can't use O_PATH fds. It needs a fully functional pipe. And
I was worried that just enabling them would break it. That's probably
not an issue because the code checks if (!(pipe->f_mode & FMODE_CAN_WRITE))
which isn't set for FMODE_PATH/O_PATH file descriptors. So that's
probably safe. So I agree we could erradicate this distinction for now.