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 ?
* 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.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287
