On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > Hey Alan, > > Thank you very much for your work in maintaining fusefs. I only use > fusefs in very limited circumstances, so take what I'm about to say > with a grain of salt. > > On Thu, Mar 21, 2019 at 09:43:07AM -0600, Alan Somers wrote: > > fusefs has several sysctl knobs that seem to be workarounds for bugs > > in particular fuse daemons. However, there is no indication as to > > which those daemons are, neither in the code nor in SVN. All of the > > workarounds are at least 6.5 years old, so the original bugs may have > > been fixed already. Since the original bugs aren't documented, I > > consider these workarounds to be unmaintainable, and I'm planning to > > delete them unless anybody objects. Please pipe up if you still use > > them! > > > > vfs.fusefs.mmap_enable: If non-zero, and data_cache_mode is also > > non-zero, enable mmap(2) of FUSE files > > I'm curious if the security impacts of removing the toggle to disable > mmap support for fusefs. Is there a per-fusefs replacement for > mmap_enable? From a security perspective, it would be nice to keep the > ability to disable mapping of files mounted on a fusefs.
As a matter of fact, there are three other ways to disable mmap: 1) Set vfs.fusefs.data_cache_mode=0. This completely disables caching file data, which precludes mmap. 2) Use the undocumented -o no_datacache mount option, which does the same thing on a per-mount basis. 3) Use the undocumented -o no_mmap mount option, which disables mmap on a per-mount basis. Are you aware of any general security problems with using mmap? Anything that would apply to fusefs but not other filesystems? -Alan _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
