linux-kernel - Re: [PATCH v3 2/3] fs: fuse: add backing

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: <CAJfpegs-SbCUA-nGnnoHr=UUwzzNKuZ9fOB86+jgxM6RH4twAA@mail.gmail.com>
Date: Mon, 12 May 2025 12:06:19 +0200
From: Miklos Szeredi <miklos@...redi.hu>
To: Amir Goldstein <amir73il@...il.com>
Cc: Chen Linxuan <chenlinxuan@...ontech.com>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Christian Brauner <brauner@...nel.org>
Subject: Re: [PATCH v3 2/3] fs: fuse: add backing_files control file

On Mon, 12 May 2025 at 11:23, Amir Goldstein <amir73il@...il.com> wrote:

> The way I see it is, generic vs. specialized have pros and cons
> There is no clear winner.
> Therefore, investing time on the getxattr() direction without consensus
> with vfs maintainer is not wise IMO.

AFAIU Christian is hung up about getting a properly sized buffer for the result.

But if the data is inherently variable sized, adding specialized
interface is not going to magically solve that.

Instead we can concentrate on solving the buffer sizing problem
generally, so that all may benefit.

> The problem I see with this scheme is that it is not generic enough.
> If lsof is to support displaying fuse backing files, then it needs to
> know specifically about those magic xattrs.

Yeah, I didn't think that through.  Need some *standard* names.

> Because lsof only displays information about open files, I think
> it would be better to come up with a standard tag in fdinfo for lsof
> to recognize, for example:
>
> hidden_file: /path/to/hidden/file
> hidden_files_list: /path/to/connections/N/backing_files

Ugh.

> Making an interface more hierarchic than hidden_files_list:
> is useless because lsof traverses all fds anyway to filter by
> name pattern and I am very sceptical of anyone trying to
> push for an API get_open_fds_by_name_pattern()...

The problem is that hidden files are hidden, lsof can't traverse them
normally.  It would be good to unhide them in some ways, and for me
that would at least mean that you can

 1) query the path (proc/PID/fd/N link)
 2) query fdinfo
 3) query hidden files

And by recursivity I mean that third point.

Thanks,
Miklos