Re: [PATCH RFC] fuse: add generic file store

On Wed, Jun 16, 2021 at 2:53 AM Enrico Weigelt, metux IT consult
[off-list ref] wrote:

On 11.06.21 14:46, Peng Tao wrote:

quoted

quoted

* it just stores fd's I don't see anything where it is actually returned
    to some open() operation.

The FUSE_DEV_IOC_RESTORE_FD ioctl returns the opened fd to a different process.

So, just open() a file on a fuse fs can't restore the fd directly
(instead of opening a new file) ? If that's the case, that would mean,
userland has to take very special actions in order to get it. Right ?

Yes.

quoted

quoted

* the store is machine wide global - everybody uses the same number
    space, dont see any kind of access conrol ... how about security ?

The idea is that anyone capable of opening /dev/fuse can retrieve the FD.

quoted

I don't believe that just storing the fd's somewhere is really helpful
for that purpose - the fuse server shall be able to reply the open()
request with an fd, which then is directly transferred to the client.

Could you describe your use case a bit? How does your client talk to
your server? Through open syscall or through some process-to-process
RPC calls?

I'd like to write synthetic file systems (file servers) that allows
certain unprivileged processes (in some confined environment) directly
open()ing prepared file descriptors (e.g. devices, sockets, etc) that it
isn't allowed to open directly (but the server obviously is). Those fds
could be prepared in any ways (eg. sealed, seek'ed, already connected
sockets, etc).

The client thinks it just open()'s a normal file, but actually gets some
fd prepared elsewhere.

Oh, nop, that is not how the current RFC works. I see two gaps:
1. /dev/fuse is not accessible to all processes by default
2. open() syscall doesn't take enough arguments to tell the kernel
which file's fd it wants.

It seems that a proper solution to your use case is to:
1. extend the open() syscall to take a flag like FOPEN_FUSE_OPEN_FD (I
agree it's a bad name;)
2. FUSE kernel passes such a flag to fuse daemon
3. FUSE userspace daemon opens the file in the underlying file system,
store it to a kernel FD store, then return its IDR in the reply to
FUSE_OPEN API
4. FUSE kernel looks up underlying FD with the IDR, install it in the
calling process FD table, and return the new FD to the application

Is it what you want? It looks doable and is indeed an extension to the
current RFC.

Cheers,
Tao
-- 
Into Sth. Rich & Strange