On Fri, Feb 7, 2025 at 4:46 PM Christian Brauner <brauner@xxxxxxxxxx> 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@xxxxxxxxxx>
> ---
> 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.
