Re: HEAD'S UP: fusefs sysctls going away
On Thu, Mar 21, 2019 at 10:00 AM Shawn Webb wrote: > > On Thu, Mar 21, 2019 at 09:55:15AM -0600, Alan Somers wrote: > > On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb > > 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. > > Awesome! I wasn't aware of these. Thanks! > > > > > Are you aware of any general security problems with using mmap? > > Anything that would apply to fusefs but not other filesystems? > > Primarily because I trust the filesystems natively implemented in my > OS more than I trust some (potentially random) fusefs module. > > For example, if I'm in a shared hosting environment, implemented with > jails, and I let the customer mount a fusefs module in the jail (which > is now possible, if I remember right), then I must trust that the > module's mmap integration is properly implemented. I'm not sure I > personally am okay with that level of trust. Ah, well you needn't worry about that. mmap is handled entirely within the kernel. The userland fusefs module only sees writes and reads. From userland's perspective, the only real difference is that mmap()ed writes don't identify the pid of the originating process, whereas direct writes do (except when vfs.fusefs.data_cache_mode==2). > > However, the point is moot now that you documented the three ways to > disable mmap (two of which work on a per-mount basis). ___ 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"
Re: HEAD'S UP: fusefs sysctls going away
On Thu, Mar 21, 2019 at 09:55:15AM -0600, Alan Somers wrote: > On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb 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. Awesome! I wasn't aware of these. Thanks! > > Are you aware of any general security problems with using mmap? > Anything that would apply to fusefs but not other filesystems? Primarily because I trust the filesystems natively implemented in my OS more than I trust some (potentially random) fusefs module. For example, if I'm in a shared hosting environment, implemented with jails, and I let the customer mount a fusefs module in the jail (which is now possible, if I remember right), then I must trust that the module's mmap integration is properly implemented. I'm not sure I personally am okay with that level of trust. However, the point is moot now that you documented the three ways to disable mmap (two of which work on a per-mount basis). Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
Re: HEAD'S UP: fusefs sysctls going away
On Thu, Mar 21, 2019 at 9:49 AM Shawn Webb 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"
Re: HEAD'S UP: fusefs sysctls going away
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. Thanks, -- Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE signature.asc Description: PGP signature
HEAD'S UP: fusefs sysctls going away
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.fix_broken_io: If non-zero, print a diagnostic warning if a userspace filesystem returns EIO on reads of recently extended portions of files vfs.fusefs.sync_resize: If a cached write extended a file, inform FUSE filesystem of the changedsize immediately subsequent to the issued writes vfs.fusefs.refresh_size: If non-zero, and no dirty file extension data is buffered, fetch file size before write operations vfs.fusefs.mmap_enable: If non-zero, and data_cache_mode is also non-zero, enable mmap(2) of FUSE files vfs.fusefs.data_cache_invalidate: If non-zero, discard cached clean file data when there are no active file users -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"
