Re: HEAD'S UP: fusefs sysctls going away
W dniu 06.04.2019 o 17:28, Alan Somers pisze: > On Sat, Apr 6, 2019 at 8:52 AM Marek Zarychta > wrote: > After recent changes in fusefs code I am getting such panics regularly on amd64: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address= 0x248 fault code= supervisor read data , page not present instruction pointer= 0x20:0x82d6250c stack pointer= 0x28:0xfe005dc2c630 frame pointer= 0x28:0xfe005dc2c7b0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process= 2016 (mount_fusefs) trap number= 12 panic: page fault cpuid = 3 time = 1554528396 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe005dc2c2e0 vpanic() at vpanic+0x19d/frame 0xfe005dc2c330 panic() at panic+0x43/frame 0xfe005dc2c390 trap_fatal() at trap_fatal+0x394/frame 0xfe005dc2c3f0 trap_pfault() at trap_pfault+0x49/frame 0xfe005dc2c450 trap() at trap+0x29f/frame 0xfe005dc2c560 calltrap() at calltrap+0x8/frame 0xfe005dc2c560 --- trap 0xc, rip = 0x82d6250c, rsp = 0xfe005dc2c630, rbp = 0xfe005dc2c7b0 --- fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfe005dc2c7b0 vfs_domount() at vfs_domount+0xace/frame 0xfe005dc2c9e0 vfs_donmount() at vfs_donmount+0x934/frame 0xfe005dc2ca80 sys_nmount() at sys_nmount+0x69/frame 0xfe005dc2cac0 amd64_syscall() at amd64_syscall+0x36e/frame 0xfe005dc2cbf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe005dc2cbf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp = 0x7fffe128, rbp = 0x7fffe730 --- KDB: enter: panic Last time I have checked it happened on FreeBSD 13.0-CURRENT #21 r345948: Fri Apr 5 17:12:53 CEST 2019. As a workaround loading fusefs.ko and fuse.ko modules can be disabled. -- Marek Zarychta >>> Thanks for the bug report. This is probably fixed by r345419 (which >>> hasn't been merged to head yet). If so, then it indicates that your fuse >>> daemon >>> is doing something wrong. What fuse file system are you trying to use, and >>> what command are you using to start it? >>> -Alan >> XFCE4 desktop environment seems to be the culprit of the whole anxiety. >> It has installed fusefs-libs-2.9.9 as a dependency. I get these panics >> during the XFCE session startup. Furthermore, I haven't any fusefs >> packages installed beside mentioned fusefs-libs. >> >> -- >> Marek Zarychta > > Then the culprit is probably /usr/local/libexec/gvfsd-fuse. But on my > XFCE4 system, that command never runs. I don't know why not. Try this > patch: > https://reviews.freebsd.org/D19836 > > -Alan Thank you for the fast-tracked patch. It resolves the issue. I have XFCE4 coexisting with Gnome and some extra, non-native disk partitions on this workstation, this is probably the cause that /usr/local/libexec/gvfsd-fuse comes into play. -- Marek Zarychta signature.asc Description: OpenPGP digital signature
Re: HEAD'S UP: fusefs sysctls going away
On Sat, Apr 6, 2019 at 8:52 AM Marek Zarychta wrote: > > W dniu 06.04.2019 o 15:39, Alan Somers pisze: > > On Fri, Apr 5, 2019 at 11:48 PM Marek Zarychta < > > zarych...@plan-b.pwste.edu.pl> wrote: > > > >> W dniu 21.03.2019 o 17:03, Alan Somers pisze: > >>> On Thu, Mar 21, 2019 at 10:00 AM Shawn Webb < > shawn.w...@hardenedbsd.org> > >> 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 < > 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. > 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). > >> After recent changes in fusefs code I am getting such panics regularly > >> on amd64: > >> > >> > >> Fatal trap 12: page fault while in kernel mode > >> cpuid = 3; apic id = 03 > >> fault virtual address= 0x248 > >> fault code= supervisor read data , page not present > >> instruction pointer= 0x20:0x82d6250c > >> stack pointer= 0x28:0xfe005dc2c630 > >> frame pointer= 0x28:0xfe005dc2c7b0 > >> code segment= base 0x0, limit 0xf, type 0x1b > >> = DPL 0, pres 1, long 1, def32 0, gran 1 > >> processor eflags= interrupt enabled, resume, IOPL = 0 > >> current process= 2016 (mount_fusefs) > >> trap number= 12 > >> panic: page fault > >> cpuid = 3 > >> time = 1554528396 > >> KDB: stack backtrace: > >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > >> 0xfe005dc2c2e0 > >> vpanic() at vpanic+0x19d/frame 0xfe005dc2c330 > >> panic() at panic+0x43/frame 0xfe005dc2c390 > >> trap_fatal() at trap_fatal+0x394/frame 0xfe005dc2c3f0 > >> trap_pfault() at trap_pfault+0x49/frame 0xfe005dc2c450 > >> trap() at trap+0x29f/frame 0xfe005dc2c560 > >> calltrap() at calltrap+0x8/frame 0xfe005dc2c560 > >> --- trap 0xc, rip = 0x82d6250c, rsp = 0xfe005dc2c630, rbp = > >> 0xfe005dc2c7b0 --- > >> fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfe005dc2c7b0 > >> vfs_domount() at vfs_domount+0xace/frame 0xfe005dc2c9e0 > >> vfs_donmount() at vfs_donmount+0x934/frame 0xfe005dc2ca80 >
Re: HEAD'S UP: fusefs sysctls going away
W dniu 06.04.2019 o 15:39, Alan Somers pisze: > On Fri, Apr 5, 2019 at 11:48 PM Marek Zarychta < > zarych...@plan-b.pwste.edu.pl> wrote: > >> W dniu 21.03.2019 o 17:03, Alan Somers pisze: >>> 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). >> After recent changes in fusefs code I am getting such panics regularly >> on amd64: >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 3; apic id = 03 >> fault virtual address= 0x248 >> fault code= supervisor read data , page not present >> instruction pointer= 0x20:0x82d6250c >> stack pointer= 0x28:0xfe005dc2c630 >> frame pointer= 0x28:0xfe005dc2c7b0 >> code segment= base 0x0, limit 0xf, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags= interrupt enabled, resume, IOPL = 0 >> current process= 2016 (mount_fusefs) >> trap number= 12 >> panic: page fault >> cpuid = 3 >> time = 1554528396 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe005dc2c2e0 >> vpanic() at vpanic+0x19d/frame 0xfe005dc2c330 >> panic() at panic+0x43/frame 0xfe005dc2c390 >> trap_fatal() at trap_fatal+0x394/frame 0xfe005dc2c3f0 >> trap_pfault() at trap_pfault+0x49/frame 0xfe005dc2c450 >> trap() at trap+0x29f/frame 0xfe005dc2c560 >> calltrap() at calltrap+0x8/frame 0xfe005dc2c560 >> --- trap 0xc, rip = 0x82d6250c, rsp = 0xfe005dc2c630, rbp = >> 0xfe005dc2c7b0 --- >> fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfe005dc2c7b0 >> vfs_domount() at vfs_domount+0xace/frame 0xfe005dc2c9e0 >> vfs_donmount() at vfs_donmount+0x934/frame 0xfe005dc2ca80 >> sys_nmount() at sys_nmount+0x69/frame 0xfe005dc2cac0 >> amd64_syscall() at amd64_syscall+0x36e/frame 0xfe005dc2cbf0 >> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe005dc2cbf0 >> --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp = >> 0x7fffe128, rbp = 0x7fffe730
Re: HEAD'S UP: fusefs sysctls going away
On Fri, Apr 5, 2019 at 11:48 PM Marek Zarychta < zarych...@plan-b.pwste.edu.pl> wrote: > > W dniu 21.03.2019 o 17:03, Alan Somers pisze: > > 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). > > After recent changes in fusefs code I am getting such panics regularly > on amd64: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address= 0x248 > fault code= supervisor read data , page not present > instruction pointer= 0x20:0x82d6250c > stack pointer= 0x28:0xfe005dc2c630 > frame pointer= 0x28:0xfe005dc2c7b0 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process= 2016 (mount_fusefs) > trap number= 12 > panic: page fault > cpuid = 3 > time = 1554528396 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe005dc2c2e0 > vpanic() at vpanic+0x19d/frame 0xfe005dc2c330 > panic() at panic+0x43/frame 0xfe005dc2c390 > trap_fatal() at trap_fatal+0x394/frame 0xfe005dc2c3f0 > trap_pfault() at trap_pfault+0x49/frame 0xfe005dc2c450 > trap() at trap+0x29f/frame 0xfe005dc2c560 > calltrap() at calltrap+0x8/frame 0xfe005dc2c560 > --- trap 0xc, rip = 0x82d6250c, rsp = 0xfe005dc2c630, rbp = > 0xfe005dc2c7b0 --- > fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfe005dc2c7b0 > vfs_domount() at vfs_domount+0xace/frame 0xfe005dc2c9e0 > vfs_donmount() at vfs_donmount+0x934/frame 0xfe005dc2ca80 > sys_nmount() at sys_nmount+0x69/frame 0xfe005dc2cac0 > amd64_syscall() at amd64_syscall+0x36e/frame 0xfe005dc2cbf0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe005dc2cbf0 > --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp = > 0x7fffe128, rbp = 0x7fffe730 --- > KDB: enter: panic > > Last time I have checked it happened on FreeBSD 13.0-CURRENT
Re: HEAD'S UP: fusefs sysctls going away
W dniu 21.03.2019 o 17:03, Alan Somers pisze: > 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). After recent changes in fusefs code I am getting such panics regularly on amd64: Fatal trap 12: page fault while in kernel mode cpuid = 3; apic id = 03 fault virtual address = 0x248 fault code = supervisor read data , page not present instruction pointer = 0x20:0x82d6250c stack pointer = 0x28:0xfe005dc2c630 frame pointer = 0x28:0xfe005dc2c7b0 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2016 (mount_fusefs) trap number = 12 panic: page fault cpuid = 3 time = 1554528396 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe005dc2c2e0 vpanic() at vpanic+0x19d/frame 0xfe005dc2c330 panic() at panic+0x43/frame 0xfe005dc2c390 trap_fatal() at trap_fatal+0x394/frame 0xfe005dc2c3f0 trap_pfault() at trap_pfault+0x49/frame 0xfe005dc2c450 trap() at trap+0x29f/frame 0xfe005dc2c560 calltrap() at calltrap+0x8/frame 0xfe005dc2c560 --- trap 0xc, rip = 0x82d6250c, rsp = 0xfe005dc2c630, rbp = 0xfe005dc2c7b0 --- fuse_vfsop_mount() at fuse_vfsop_mount+0x5dc/frame 0xfe005dc2c7b0 vfs_domount() at vfs_domount+0xace/frame 0xfe005dc2c9e0 vfs_donmount() at vfs_donmount+0x934/frame 0xfe005dc2ca80 sys_nmount() at sys_nmount+0x69/frame 0xfe005dc2cac0 amd64_syscall() at amd64_syscall+0x36e/frame 0xfe005dc2cbf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe005dc2cbf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8002d510a, rsp = 0x7fffe128, rbp = 0x7fffe730 --- KDB: enter: panic Last time I have checked it happened on FreeBSD 13.0-CURRENT #21 r345948: Fri Apr 5 17:12:53 CEST 2019. As a workaround loading fusefs.ko and fuse.ko modules can be disabled. -- Marek Zarychta signature.asc Description: OpenPGP digital signature
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"
