| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Using fuse_session_exit() followed by fuse_session_unmount() ensures
that a proper cleanup and shutdown is performed.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug occurs when a filesystem client reads a directory until the end,
seeks using seekdir() to some valid non-zero position and calls
readdir(). A valid 'struct dirent *' is expected, but NULL is returned
instead. Pseudocode demonstrating the bug:
DIR *dp = opendir("some_dir");
struct dirent *de = readdir(dp);
/* Get offset of the second entry */
long offset = telldir(dp);
/* Read directory until the end */
while (de)
de = readdir(de);
seekdir(dp, offset);
de = readdir(dp);
/* de must contain the second entry, but NULL is returned instead */
The reason of the bug is that when the end of directory is reached, the
kernel calls FUSE_READDIR op with an offset at the end of directory, so
the filesystem's .readdir callback never calls the filler function, and
we end up with dh->filled set to 1. After seekdir(), FUSE_READDIR is
called again with a new offset, but this time the filesystem's .readdir
callback is never called, and an empty reply is returned.
Fix by setting dh->filled to 1 only when zero offsets are given to
filler function.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
$ _FUSE_COMMFD=1 priv_strace -s8000 -e trace=mount util/fusermount3 /proc/self/fd
mount("/dev/fuse", ".", "fuse", MS_NOSUID|MS_NODEV, "fd=3,rootmode=40000,user_id=379777,group_id=5001") = 0
sending file descriptor: Socket operation on non-socket
+++ exited with 1 +++
After:
$ _FUSE_COMMFD=1 priv_strace -s8000 -e trace=mount util/fusermount3 /proc/self/fd
util/fusermount3: mounting over filesystem type 0x009fa0 is forbidden
+++ exited with 1 +++
This patch could potentially have security
impact on some systems that are configured with allow_other;
see https://launchpad.net/bugs/1530566 for an example of how a similar
issue in the ecryptfs mount helper was exploitable. However, the FUSE
mount helper performs slightly different security checks, so that exact
attack doesn't work with fusermount; I don't know of any specific attack
you could perform using this, apart from faking the SELinux context of your
process when someone's looking at a process listing. Potential targets for
overwrite are (looking on a system with a 4.9 kernel):
writable only for the current process:
/proc/self/{fd,map_files}
(Yes, "ls -l" claims that you don't have write access, but that's not true;
"find -writable" will show you what access you really have.)
writable also for other owned processes:
/proc/$pid/{sched,autogroup,comm,mem,clear_refs,attr/*,oom_adj,
oom_score_adj,loginuid,coredump_filter,uid_map,gid_map,projid_map,
setgroups,timerslack_ns}
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Blacklists are notoriously fragile; especially if the kernel wishes to add
some security-critical mount option at a later date, all existing systems
with older versions of fusermount installed will suddenly have a security
problem.
Additionally, if the kernel's option parsing became a tiny bit laxer, the
blacklist could probably be bypassed.
Whitelist known-harmless flags instead, even if it's slightly more
inconvenient.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If an attacker wishes to use the default configuration instead of the
system's actual configuration, they can attempt to trigger a failure in
read_conf(). This only permits increasing mount_max if it is lower than the
default, so it's not particularly interesting. Still, this should probably
be prevented robustly; bail out if funny stuff happens when we're trying to
read the config.
Note that the classic attack trick of opening so many files that the
system-wide limit is reached won't work here - because fusermount only
drops the fsuid, not the euid, the process is running with euid=0 and
CAP_SYS_ADMIN, so it bypasses the number-of-globally-open-files check in
get_empty_filp() (unless you're inside a user namespace).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old code permits the following behavior:
$ _FUSE_COMMFD=10000 priv_strace -etrace=mount -s200 fusermount -o 'foobar=\,allow_other' mount
mount("/dev/fuse", ".", "fuse", MS_NOSUID|MS_NODEV, "foobar=\\,allow_other,fd=3,rootmode=40000,user_id=1000,group_id=1000") = -1 EINVAL (Invalid argument)
However, backslashes do not have any special meaning for the kernel here.
As it happens, you can't abuse this because there is no FUSE mount option
that takes a string value that can contain backslashes; but this is very
brittle. Don't interpret "escape characters" in places where they don't
work.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, in the kernel, copy_mount_options() copies in one page of
userspace memory (or less if some of that memory area is not mapped).
do_mount() then writes a null byte to the last byte of the copied page.
This means that mount option strings longer than PAGE_SIZE-1 bytes get
truncated silently.
Therefore, this can happen:
user@d9-ut:~$ _FUSE_COMMFD=10000 fusermount -o "$(perl -e 'print ","x4000')" mount
sending file descriptor: Bad file descriptor
user@d9-ut:~$ grep /mount /proc/mounts
/dev/fuse /home/user/mount fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0
user@d9-ut:~$ fusermount -u mount
user@d9-ut:~$ _FUSE_COMMFD=10000 fusermount -o "$(perl -e 'print ","x4050')" mount
sending file descriptor: Bad file descriptor
user@d9-ut:~$ grep /mount /proc/mounts
/dev/fuse /home/user/mount fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=100 0 0
user@d9-ut:~$ fusermount -u mount
user@d9-ut:~$ _FUSE_COMMFD=10000 fusermount -o "$(perl -e 'print ","x4051')" mount
sending file descriptor: Bad file descriptor
user@d9-ut:~$ grep /mount /proc/mounts
/dev/fuse /home/user/mount fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=10 0 0
user@d9-ut:~$ fusermount -u mount
user@d9-ut:~$ _FUSE_COMMFD=10000 fusermount -o "$(perl -e 'print ","x4052')" mount
sending file descriptor: Bad file descriptor
user@d9-ut:~$ grep /mount /proc/mounts
/dev/fuse /home/user/mount fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1 0 0
user@d9-ut:~$ fusermount -u mount
I'm not aware of any context in which this is actually exploitable - you'd
still need the UIDs to fit, and you can't do it if the three GIDs of the
process don't match (in the case of a typical setgid binary), but it does
look like something that should be fixed.
I also plan to try to get this fixed on the kernel side.
|
| | |
|
| |
|
|
| |
Fixes: #224
|
| |
|
|
| |
Single quotes will become an error in a future meson release.
|
| |
|
|
| |
Source: Miklos Szeredi on fuse-devel, Wednesday, 4 July 2018 15:29.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
the filehandle from opendir is passed to releasedir - there is no
closedir function in fuse_operations
|
| |
|
|
| |
Fix conditionals as per maintainer's request.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Linux performs the dir loop check (rename(a, a/b/c)
or rename(a/b/c, a), etc.) in kernel. Unfortunately
other systems do not perform this check (e.g. FreeBSD).
This results in a deadlock in get_path2, because libfuse
did not expect to handle such cases.
We add a check_dir_loop function that performs the dir
loop check in user mode and enable it on systems that
need it.
|
| | |
|
| |
|
|
| |
Fixes: #222.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Silence below warnings which appear if IGNORE_MTAB is defined.
[59/64] Compiling C object 'util/fusermount3@exe/fusermount.c.o'.
../util/fusermount.c:493:12: warning: function declaration isn't a prototype [-Wstrict-prototypes]
static int count_fuse_fs()
^~~~~~~~~~~~~
../util/fusermount.c: In function 'unmount_fuse':
../util/fusermount.c:508:46: warning: unused parameter 'quiet' [-Wunused-parameter]
static int unmount_fuse(const char *mnt, int quiet, int lazy)
^~~~~
|
| | |
|
| |
|
|
|
| |
No functional difference expected, but should still follow the standard.
http://pubs.opengroup.org/onlinepubs/009695399/functions/calloc.html
|
| |
|
|
| |
`int sig` is acutually used, so `(void) sig;` is unneeded.
|
| |
|
|
| |
Callers do (and should) use ;.
|
| | |
|
| |
|
|
|
| |
Newest Meson requires Python 3.5 which isn't available in Trusty.
Pip version pin no longer necessary.
|
| | |
|
| | |
|
| |
|
|
| |
Add a configuration file with all options disabled that includes
all valid options and their description.
|
| |
|
|
|
|
|
|
|
| |
DragonFlyBSD has no "bsd" in uname, so add 'dragonfly' to conditionals.
-- e.g. uname(1) in DragonFlyBSD
[root@ ~]# uname
DragonFly
[root@ ~]# python -c "import sys; print(sys.platform)"
dragonfly5
|
| |
|
|
|
|
|
| |
Ensure that conf is always zero before it's read from to prevent
sporadic failure at startup if higher layers were build against
version 3.0
Signed-off-by: Ashley Pittman <ashley.m.pittman@intel.com>
|
| | |
|
| |
|
| |
Accept (and ignore) nofail mount option
|
| | |
|
| |
|
| |
Fix spelling errors
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This change is bogus. fuse_module_factory_t is already a pointer
type. Additionally, if dlsym returns NULL, then you will be
dereferencing it causing a segfault. In my testing, a segfault will
happen even if dlsym returns successfully.
Thanks to Michael Theall for spotting!
|
| |
|
|
|
| |
Were not installing the corresponding binaries either, since those
are provided by the BSD base system.
|
| |
|
|
| |
Emacs now has a proper meson mode :-).
|
Benjamin Barenblat
Robo Shimmer
Rostislav Skudnov
Nikolaus Rath
Rostislav
Jann Horn
Laszlo Boszormenyi (GCS)
William Woodruff
Carl Edquist
Bill Zissimooulos
Tomohiro Kusumi
admorgan
Ashley Pittman
Mateusz Urbańczyk
Josh Soref
divinity76