Date: Thu, 07 Mar 2019 23:38:03 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 236379] [FUSE] fuse(4) writes from aio(4) don't set the fuse_out_header.pid field correctly Message-ID: <bug-236379-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D236379 Bug ID: 236379 Summary: [FUSE] fuse(4) writes from aio(4) don't set the fuse_out_header.pid field correctly Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: asomers@FreeBSD.org Every FUSE operation includes the pid of the process that issued the reques= t.=20 However, when an aiod kernel process writes to a fuse-backed file on behalf= of a regular user process, fuse(4) only sees aiod's pid_t, not the user proces= s's. This can cause a fuse filesystem daemon to incorrectly authenticate write commands There are three possible solutions: 1) Set the pid field correctly. The aio daemon already keeps track of it, but doesn't send that information to fuse(4). It's not obvious how. a) Perhaps stuff it into a spare field in struct ucred? b) Define custom fileops for fuse and store the pid that opened a file in struct file.f_data? But this would cause problems when sending a file descriptor from one process to another with sendmsg. 2) Set FUSE_WRITE_CACHE, just like writes from the pager. Currently, howev= er, fuse(4) isn't aware of which operations come from aiod. 3) Alternatively, since FUSE_WRITE is an asynchronous operation, aio(4) could learn to bypass VOP_WRITE and use a threadless direct dispatch like it currently does for disks. That would improve performance, too. This bug probably applies to aio reads as well, but I haven't checked yet. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-236379-227>