linux-kernel - Re: [PATCH v1 0/2] RFC: Extend fuse-passthrough to directories

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: <CAL=UVf707OokQUuhzbvrweFziLVmiDD3TFs_WG2hRY0-snw7Wg@mail.gmail.com>
Date: Thu, 19 Jun 2025 12:50:26 -0700
From: Paul Lawrence <paullawrence@...gle.com>
To: Amir Goldstein <amir73il@...il.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, Bernd Schubert <bernd.schubert@...tmail.fm>
Subject: Re: [PATCH v1 0/2] RFC: Extend fuse-passthrough to directories

Hi Amir,

Thank you for your detailed reply. My intent with this patch was to see if there
was interest (a definite yes) and to see what path would best get us
to our common
goal.

I'm thinking the best approach is to start with your ops_mask API. In
fact, that solves
the biggest single problem with my future patch set, which was that it
was going to be
huge and not realistically divisible, since you need everything for
directory passthrough
to work without the mask. Your way allows us to proceed in nice
logical steps, which is
much, much better. Thank you for that suggestion.

So my follow-up question is: What can I do to help get the
foundational patches you
wrote upstreamed?

In the meantime, a few thoughts on your comments. (Note that one of
the beauties of
your suggestion is that we don't need to agree on any of this to get
started - we can
discuss them in detail when we get to the specific ops that require them.)

1) Yes, let's use backing_id. I won't mention that again.

2) The backing path per dentry comes from the way dentry_open works.
If we are going to
attach a file to a lookup, we have to put something into the
fuse_dentry or the fuse_inode.
This makes more sense once you see points 3 & 4 below - without them,
we have an open
file, so why not just use it?

3) A cute idea that we had that seems to work is to allow negative
dentries as backing
dentries. It appears to work well - for instance, a create first looks
up the (negative) dentry
then creates the file into that dentry. If the lookup puts a negative
dentry as the backing
file, we can now just use vfs_create to create the backing file.

This means that only FUSE_LOOKUP and (I think) FUSE_READDIRPLUS need to have
the ability to accept backing_ids. I think is is both more elegant
conceptually, simpler to
code in the kernel *and* simpler to use in the daemon.

4) Having to open a file for it to be passed into a lookup is
problematic. Imagine
readdirplus on a large folder. We would need to open every single
backing file, and it
would stay open until the dentry was removed from the cache.

Both of these suggest that rather than just passing a backing_id to FUSE_LOOKUP
and FUSE_READDIRPLUS we should be able to pass a backing_id and a relative path.
This is where the idea of putting the backing path into the fuse
dentry comes from.

I don't *think* this creates any security issues, so long as the
relative path is traversed
in the context of the daemon. (We might want to ban '..' and traverses
over file systems.)
Again, these are details we can debate when the patches are ready for
discussion.

But again, let's start with your patch set. What are the next steps in
taking it upstream?
And which are the next ops you would like to see implemented? I would
be happy to take
a stab at one or two.

Paul