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

[Christian Brauner <brauner@kernel.org>]

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.