Updated README. - susmb - mounting of SMB/CIFS shares via FUSE
 (HTM) git clone git://git.codemadness.org/susmb
 (DIR) Log
 (DIR) Files
 (DIR) Refs
 (DIR) README
 (DIR) LICENSE
       ---
 (DIR) commit 3d25ee3102e4fb4c47dec7d0ccbc2d24a4c0ecf8
 (DIR) parent 2421826df0aee52d6dd48812f2adc3c0f96c3323
 (HTM) Author: geoff <devnull@localhost>
       Date:   Sat,  8 Jul 2006 20:28:16 +0000
       
       Updated README.
       
       Diffstat:
         M doc/README                          |      27 ++++++++++++++++++++++-----
       
       1 file changed, 22 insertions(+), 5 deletions(-)
       ---
 (DIR) diff --git a/doc/README b/doc/README
       @@ -1,17 +1,34 @@
       -usmb - Unprivileged mounting of SMB shares via FUSE
       -===================================================
       +usmb - Unprivileged mounting of SMB/CIFS shares via FUSE
       +========================================================
        
        Introduction
        ------------
        
       -usmb lets you mount SMB shares via FUSE, in the vein of the Map Network Drive
       -functionality in Windows.
       +usmb lets you mount SMB/CIFS shares via FUSE, in the vein of the Map Network
       +Drive functionality in Windows.
        
        The two existing FUSE filesystems that I know of (SMB for FUSE and fusesmb)
        mimic Windows' Network Neighbourhood by letting you browse hosts and shares.
       -This means that you must run a NetBIOS name server, and can't see hosts that
       +This means that you must run a NetBIOS name server and can't see hosts that
        aren't advertised via NetBIOS.
        
       +You can build [u]mount.cifs in the Samba distribution and install them
       +setuid root, but that has its own set of security implications. In any
       +case there's no need for network filesystem code to be in the kernel:
       +bugs could lead to remotely exploitable kernel vulnerabilities. Running
       +the SMB client code in user space as an unprivileged user limits the
       +potential damage due to bugs.
       +
       +A user space implementation will be slower than a kernel filesystem since
       +the data must be copied in and out of the fuse process' context as well as
       +in/out of the user process' context. Mitigating factors are:
       +
       +1. Increased security.
       +2. Containment of bugs.
       +3. Throughput is more likely to be limited by network bandwidth rather than
       +   local memory copying.
       +4. The client filesystem code can be upgraded/fixed without kernel changes.
       +
        
        Pre-Requisites
        --------------