On 8/27/24 10:32, Han-Wen Nienhuys wrote: > Sure. Who is the libfuse maintainer these days? https://github.com/libfuse/libfuse/blob/master/AUTHORS is up to date > For full transparency, I just work on the go-fuse library for fun, I > don't have direct applications for passthrough at the moment. That > said, I have been trying to make it go faster, and obviously bypassing > user-space for reads/writes helps in a big way. Keep in mind that passthrough isn't some simple feature that you enable or not. There is a decent amount of subtleness to using it and it must be very explicitly managed by the library user. It also will only work where underlying FD is a filesystem. And for anyone doing union filesystem like stuff, such as myself, passthrough has limited use outside read/write. Even then the user will have to give up certain features to enable since the FUSE server no longer has control. Including errors. > The most annoying part of the current functionality is the > CAP_SYS_ADMIN restriction; I am not sure everyone is prepared to run > their file systems as root. Could the ioctl check that the file was > opened as O_RDWR, and stop checking for root? This is a security feature ATM. And yes, it is a PITA in cases like mine where you have to set{u,g}id to the calling request {u,g}id to ensure proper authn/authz. In my prototyping with passthrough feature I'm having to change to uid/gid, change back to root to setup passthrough, then change back to uid/gid. Not the end of the world but... > So in summary, my wishlist for passthrough (decreasing importance): > > 1. get rid of cap_sys_admin requirement > 2. allow passthrough for all file operations (fallocate, fsync, flush, > setattr, etc.) I'd generally agree. Having to have a singular backing fd for a node is inconvenient in my usecase but I totally understand the reason. If there was a way to remove the need to have a global construct to manage the resource, it'd be nice, but not sure there is a good way of doing that. Perhaps if certain requests, like open, could have a fh object like other instructions and the kernel guaranteed there was no race condition with setting it then perhaps that could be an option. Like... if lookup had a fh that was attached to the node.
