On Friday, April 12th, 2024 at 5:08 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > Sounds good, except returning ENOENT to user for open with zero backing id > is confusing, so I think it has to be EIO like all the other illegal > passthrough open replies. > > Thanks, > Amir. Been at the Texas Linux Fest past couple days so I've not really had time to look at what you've done for lookup yet. Will do so soon. RE fh: I think adding a "fh" to more of the protocol could be useful. I find it extremely convenient with file lifecycle management and if it could exist for node lifecycle too that could simplify server code. This just came to mind while trying to rework my server to use passthrough and haven't dug into the code to see how plausible it is. RE FOPEN_PASSTHROUGH and complications I've found: I've found another practical issue. Granted this is a "me" problem in how mergerfs was designed but none the less a, I think, serious issue for me. mergerfs is multiuser. It runs at root, multithreaded, and will seteuid to ensure the syscalls it makes are in the user context of the client app (where appropriate.) Unless there is some API I'm unfamiliar with there is no way in Linux to open an existing fd. Instead you are expected to open /proc/self/fd/%d. But in my case since the process is running as root /proc/self/fd/ is owned by root:root and mode 0500. While a chown will return success on /proc/self/fd/ it has no effect and a chmod fails with EPERM. So non-root can't open the file. The only thing I can think of to do is to store all the details about the file and on future opens open the filepath and ensure it is the same file before returning back to the kernel otherwise return an error.
