On Mon, Nov 9, 2020 at 1:48 PM Alexey Gladkov <gladkov.alexey@xxxxxxxxx> wrote: > > This patch removes one kind of the deadlocks inside the fuse daemon. The > problem appear when the fuse daemon itself makes a file operation on its > filesystem and receives a fatal signal. > > This deadlock can be interrupted via fusectl filesystem. But if you have > many fuse mountpoints, it will be difficult to figure out which > connection to break. > > This patch aborts the connection if the fuse server receives a fatal > signal. The patch itself might be acceptable, but I have some questions. To logic of this patch says: "If a task having the fuse device open in it's fd table receives SIGKILL (and filesystem was initially mounted in a non-init user namespace), then abort the filesystem operation" You just say "server" instead of "task having the fuse device open in it's fd table" which is sloppy to say the least. It might also lead to regressions, although I agree that it's unlikely. Also how is this solving any security issue? Just create the request loop using two fuse filesystems and the deadlock avoidance has just been circumvented. So AFAICS "selling" this as a CVE fix is not appropriate. What's the reason for making this user-ns only? If we drop the security aspect, then I don't see any reason not to do this unconditionally. Also note, there's a proper solution for making fuse requests always killable, and that is to introduce a shadow locking that ensures correct fs operation in the face of requests that have returned and released their respective VFS locks. Now this would be a much more complex solution, but also a much more correct one, not having issues with correctly defining what a server is (which is not a solvable problem). Thanks, Miklos
