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@xxxxxxxxx> wrote:
> >
> > 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.
> >
>
> 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@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.
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.
