diff options
| author |  Nikolaus Rath <Nikolaus@rath.org> | 2017-01-12 10:10:34 -0800 |
|---|---|---|
| committer | Nikolaus Rath <Nikolaus@rath.org> | 2017-01-12 10:34:54 -0800 |
| commit | 9e3147feab8e313b54388df2bda8540ff2afdd02 (patch) | |
| tree | b922779bcfebc00cd7c93d5b53b4ec60c5a963d3 /README.md | |
| parent | 8d2b94a8aed49b28d053f00b77f5e14f15e71053 (diff) | |
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.
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 58 |
1 files changed, 29 insertions, 29 deletions
@@ -1,29 +1,6 @@ libfuse ======= -[](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 ------------------------------ |