linux-kernel - Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAOQ4uxgY=gYYyc62k-Xo7vgrSHgQczC_2d4d-s445GK=eWpKAQ@mail.gmail.com>
Date: Tue, 16 Dec 2025 11:51:56 +0100
From: Amir Goldstein <amir73il@...il.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Luis Henriques <luis@...lia.com>, "Darrick J. Wong" <djwong@...nel.org>, 
	Bernd Schubert <bschubert@....com>, Kevin Chen <kchen@....com>, 
	Horst Birthelmer <hbirthelmer@....com>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Matt Harvey <mharvey@...ptrading.com>, 
	kernel-dev@...lia.com
Subject: Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation

On Tue, Dec 16, 2025 at 11:40 AM Miklos Szeredi <miklos@...redi.hu> wrote:
>
> On Fri, 12 Dec 2025 at 19:12, Luis Henriques <luis@...lia.com> wrote:
> >
> > The implementation of LOOKUP_HANDLE modifies the LOOKUP operation to include
> > an extra inarg: the file handle for the parent directory (if it is
> > available).  Also, because fuse_entry_out now has a extra variable size
> > struct (the actual handle), it also sets the out_argvar flag to true.
>
> How about adding this as an extension header (FUSE_EXT_HANDLE)?  That
> would allow any operation to take a handle instead of a nodeid.
>
> Yeah, the infrastructure for adding extensions is inadequate, but I
> think the API is ready for this.
>
> > @@ -181,8 +182,24 @@ static void fuse_lookup_init(struct fuse_conn *fc, struct fuse_args *args,
> >         args->in_args[2].size = 1;
> >         args->in_args[2].value = "";
> >         args->out_numargs = 1;
> > -       args->out_args[0].size = sizeof(struct fuse_entry_out);
> > +       args->out_args[0].size = sizeof(*outarg) + outarg->fh.size;
> > +
> > +       if (fc->lookup_handle) {
> > +               struct fuse_inode *fi = NULL;
> > +
> > +               args->opcode = FUSE_LOOKUP_HANDLE;
> > +               args->out_argvar = true;
>
> How about allocating variable length arguments on demand?  That would
> allow getting rid of max_handle_size negotiation.
>
>         args->out_var_alloc  = true;
>         args->out_args[1].size = MAX_HANDLE_SZ;
>         args->out_args[1].value = NULL; /* Will be allocated to the
> actual size of the handle */
>

Keep in mind that we will need to store the file handle in the fuse_inode.
Don't you think that it is better to negotiate the max_handle_size even
if only as an upper limit?

Note that MAX_HANDLE_SZ is not even UAPI.
It is the upper limit of the moment for the open_by_handle_at() syscall.
FUSE protocol is by no means obligated to it, but sure we can use that
as the default upper limit.

>From man open_by_handle_at.2:
       It  is  the caller's responsibility to allocate the structure
with a size large enough to hold the handle returned in f_handle.
       ...(The constant MAX_HANDLE_SZ, defined in <fcntl.h>, specifies
the maximum expected size for a file handle.
       It is not a guaranteed upper limit as future filesystems may
require more space.)

Thanks,
Amir.