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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAJfpegszP+2XA=vADK4r09KU30BQd-r9sNu2Dog88yLG8iV7WQ@mail.gmail.com>
Date: Tue, 16 Dec 2025 11:39:54 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Luis Henriques <luis@...lia.com>
Cc: Amir Goldstein <amir73il@...il.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 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 */

> diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
> index 4acf71b407c9..b75744d2d75d 100644
> --- a/include/uapi/linux/fuse.h
> +++ b/include/uapi/linux/fuse.h
> @@ -690,6 +690,13 @@ enum fuse_notify_code {
>  #define FUSE_MIN_READ_BUFFER 8192
>
>  #define FUSE_COMPAT_ENTRY_OUT_SIZE 120
> +#define FUSE_COMPAT_45_ENTRY_OUT_SIZE 128
> +
> +struct fuse_file_handle {
> +       uint32_t        size;

uint16_t should be enough for everyone ;)

> +       uint32_t        type;

Please make "type" just be a part of the opaque handle.  Makes
conversion from struct file_handle to struct fuse_file_handle slightly
more complex, but api clarity is more important imo.

> +       char            handle[0];

uint8_t handle[];

Thanks,
Miklos