Rephrased security information

The permission caching bug has been present forever, is presumably
going to stay around for a while, and is of less concern if
allow_other is not used. Since allow_other is disabled by default, I
think we can safely make this warning less prominent and document the
problem when we describe allow_other.

Also, drop the travis build status. It's confusing when reading
README.md after extracting the tarball, and I am not sure who benefits
from the build status when it is shown on GitHub either.

diff --git a/README.md b/README.md
index 39e57bf4981a037ace9a7115db5fae281e40179c..8201eeba35df8b343eaeb6929ee4e79df791b3f3 100644 (file)
--- a/README.md
+++ b/README.md
@@ -1,29 +1,6 @@
 libfuse
 =======
 
-[![Build Status](https://travis-ci.org/libfuse/libfuse.svg?branch=master)](https://travis-ci.org/libfuse/libfuse)
-
-Warning: unresolved security issue
-----------------------------------
-
-Be aware that FUSE has an unresolved security bug
-([bug #15](https://github.com/libfuse/libfuse/issues/15)): if the
-`default_permissions` mount option is not used, the results of the
-first permission check performed by the file system for a directory
-entry will be re-used for subsequent accesses as long as the inode of
-the accessed entry is present in the kernel cache - even if the
-permissions have since changed, and even if the subsequent access is
-made by a different user.
-
-This bug needs to be fixed in the Linux kernel and has been known
-since 2006 but unfortunately no fix has been applied yet. If you
-depend on correct permission handling for FUSE file systems, the only
-workaround is to use `default_permissions` (which does not currently
-support ACLs), or to completely disable caching of directory entry
-attributes. Alternatively, the severity of the bug can be somewhat
-reduced by not using the `allow_other` mount option.
-
-
 About
 -----
 
@@ -79,19 +56,42 @@ If you run `make install`, the *fusermount3* program is installed
 set-user-id to root.  This is done to allow normal users to mount
 their own filesystem implementations.
 
-There must however be some limitations, in order to prevent Bad User from
-doing nasty things.  Currently those limitations are:
+To limit the harm that malicious users can do this way, *fusermount3*
+enforces the following limitations:
 
-  - The user can only mount on a mountpoint, for which it has write
+  - The user can only mount on a mountpoint for which he has write
     permission
 
-  - The mountpoint is not a sticky directory which isn't owned by the
-    user (like /tmp usually is)
+  - The mountpoint must not be a sticky directory which isn't owned by
+    the user (like /tmp usually is)
 
   - No other user (including root) can access the contents of the
     mounted filesystem (though this can be relaxed by allowing the use
-    of the `allow_other` and `allow_root` mount options in `fuse.conf`)
+    of the *allow_other* and *allow_root* mount options in
+    */etc/fuse.conf*)
+
+
+If you intend to use the *allow_other* mount options, be aware that
+FUSE has an unresolved [security
+bug](https://github.com/libfuse/libfuse/issues/15): if the
+*default_permissions* mount option is not used, the results of the
+first permission check performed by the file system for a directory
+entry will be re-used for subsequent accesses as long as the inode of
+the accessed entry is present in the kernel cache - even if the
+permissions have since changed, and even if the subsequent access is
+made by a different user. This is of little concern if the filesystem
+is accessible only to the mounting user (which has full access to the
+filesystem anyway), but becomes a security issue when other users are
+allowed to access the filesystem (since they can exploit this to
+perform operations on the filesystem that they do not actually have
+permissions for).
 
+This bug needs to be fixed in the Linux kernel and has been known
+since 2006 but unfortunately no fix has been applied yet. If you
+depend on correct permission handling for FUSE file systems, the only
+workaround is to use `default_permissions` (which does not currently
+support ACLs), or to completely disable caching of directory entry
+attributes.
 
 Building your own filesystem
 ------------------------------