[PATCH 5/5] fuse: documentation update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Add homepage pointer.

Clarify security requirements, based on discussion with Frank van
Maarseveen.

Signed-off-by: Miklos Szeredi <[email protected]>

diff -rup linux-2.6.13-rc3-mm3/Documentation/filesystems/fuse.txt linux-fuse/Documentation/filesystems/fuse.txt
--- linux-2.6.13-rc3-mm3/Documentation/filesystems/fuse.txt	2005-07-29 10:56:43.000000000 +0200
+++ linux-fuse/Documentation/filesystems/fuse.txt	2005-07-29 10:36:59.000000000 +0200
@@ -38,6 +38,11 @@ non-privileged mounts.  This opens up ne
 filesystems.  A good example is sshfs: a secure network filesystem
 using the sftp protocol.
 
+The userspace library and utilities are available from the FUSE
+homepage:
+
+  http://fuse.sourceforge.net/
+
 Mount options
 ~~~~~~~~~~~~~
 
@@ -166,14 +171,14 @@ How are requirements fulfilled?
      2) Even if 1) is solved the mount owner can change the behavior
         of other users' processes.
 
-         - It can slow down or indefinitely delay the execution of a
+         i) It can slow down or indefinitely delay the execution of a
            filesystem operation creating a DoS against the user or the
            whole system.  For example a suid application locking a
            system file, and then accessing a file on the mount owner's
            filesystem could be stopped, and thus causing the system
            file to be locked forever.
 
-         - It can present files or directories of unlimited length, or
+         ii) It can present files or directories of unlimited length, or
            directory structures of unlimited depth, possibly causing a
            system process to eat up diskspace, memory or other
            resources, again causing DoS.
@@ -186,6 +191,11 @@ How are requirements fulfilled?
 	ptrace can be used to check if a process is allowed to access
 	the filesystem or not.
 
+	Note that the ptrace check is not strictly necessary to
+	prevent B/2/i, it is enough to check if mount owner has enough
+	privilege to send signal to the process accessing the
+	filesystem, since SIGSTOP can be used to get a similar effect.
+
 I think these limitations are unacceptable?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux