On Wed, Jun 16, 2021 at 2:53 AM Enrico Weigelt, metux IT consult <lkml@xxxxxxxxx> wrote: > > On 11.06.21 14:46, Peng Tao wrote: > > >> > >> * 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. > > >> * 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. > > > >> 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
