HEAD'S UP: fusefs sysctls going away

[Alan Somers]

On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb <shawn.webb at 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