| Age | Commit message (Collapse) | Author |
|---|
|
The latest release allows a custom logger
Bug: 135341433
Test: adb shell ls /sdcard with persist.sys.fuse
Change-Id: Iaa8a2bb7b6da3f364fba41b443527a998a26549f
|
|
The unprivileged option allows to run the FUSE file system process
without privileges by dropping capabilities and preventing them from
being re-acquired via setuid / fscaps etc. To accomplish this,
mount.fuse sets up the `/dev/fuse` file descriptor and mount itself
and passes the file descriptor via the `/dev/fd/%u` mountpoint syntax
to the FUSE file system.
|
|
This adds support for a mode of operation in which a privileged parent
process opens `/dev/fuse` and takes care of mounting. The FUSE file
system daemon can then run as an unprivileged child that merely
processes requests on the FUSE file descriptor, which get passed using
the special `/dev/fd/%u` syntax for the mountpoint parameter.
The main benefit is that no privileged operations need to be performed
by the FUSE file system daemon itself directly or indirectly, so the
FUSE process can run with fully unprivileged and mechanisms like
securebits and no_new_privs can be used to prevent subprocesses from
re-acquiring privilege via setuid, fscaps, etc. This reduces risk in
case the FUSE file system gets exploited by malicious file system
data.
Below is an example that illustrates this. Note that I'm using shell
for presentation purposes, the expectation is that the parent process
will implement the equivalent of the `mount -i` and `capsh` commands.
```
\# example/hello can mount successfully with privilege
$ sudo sh -c "LD_LIBRARY_PATH=build/lib ./example/hello /mnt/tmp"
$ sudo cat /mnt/tmp/hello
Hello World!
$ sudo umount /mnt/tmp
\# example/hello fails to mount without privilege
$ sudo capsh --drop=all --secbits=0x2f -- -c 'LD_LIBRARY_PATH=build/lib ./example/hello -f /mnt/tmp'
fusermount3: mount failed: Operation not permitted
\# Passing FUSE file descriptor via /dev/fd/%u allows example/hello to work without privilege
$ sudo sh -c '
exec 17<>/dev/fuse
mount -i -o nodev,nosuid,noexec,fd=17,rootmode=40000,user_id=0,group_id=0 -t fuse hello /mnt/tmp
capsh --drop=all --secbits=0x2f -- -c "LD_LIBRARY_PATH=build/lib example/hello /dev/fd/17"
'
$ sudo cat /mnt/tmp/hello
Hello World!
$ sudo umount /mnt/tmp
```
|
|
Return different error codes from fuse_main()
|
|
Fix spelling errors
|
|
The fuse_session_loop_mt() and fuse_loop_mt() symbols are only visible
when linking against the shared object. The code in lib/, however, is
compiled *into* the shared object and should thus use the internal
names of these functions.
Surprisingly enough, the code still worked before - but only when link
time optimization was disabled.
Unfortunately, we still can't compile with LTO because it seems that
enabling LTO somehow makes the tagged symbols vanish.
Without lto, we have:
$ nm lib/libfuse3.so | grep fuse_new
0000000000011070 T fuse_new_30
0000000000010a00 t fuse_new_31
0000000000011070 T fuse_new@FUSE_3.0
0000000000010a00 T fuse_new@@FUSE_3.1
and with LTO:
$ nm lib/libfuse3.so | grep fuse_new
0000000000019a70 T fuse_new_30
0000000000019270 t fuse_new_31
See also issue #198.
|
|
|
|
|
|
this fixes building with lto, which failed since commit 503e32d01e4db00e90d7acfd81ab05386559069f
|
|
This should simplify the code a lot. It also corrects a bug in
that the (former) add_default_fsname() function actually set
the -osubtype option.
|
|
|
|
|
|
This may not make sense for all options, but it's good practice.
|
|
|
|
|
|
Both the BSD and Linux implementation actually accept mostly the same
FUSE-specific mount options. Up to now, the BSD help function appended
the output of ``mount_fusefs --help``, but looking at
http://www.unix.com/man-page/freebsd/8/mount_fusefs/ this is likely more
confusing than helpful (since the user is not actually invoking
mount_fusefs directly, most of the options don't make sense).
|
|
We now only list options that are potentially useful for an
end-user (and unlikely to accidentally break a file system). The full
list of FUSE options has been moved to the documentation of the
fuse_new() and fuse_session_new() functions.
|
|
Instead of using command line options to modify struct fuse_conn_info
before and after calling the init() handler, we now give the file system
explicit control over this.
|
|
This option really affects the behavior of the session loop, not the
low-level interface. Therefore, it does not belong in the fuse_session
object.
|
|
There's now a way to inhibit the "usage" line (which actually got lost
in commit 225c12aebf2d), which makes it easier for simply file-systems
to generate good-looking --help output.
|
|
|
|
The current behavior makes it difficult to add help for
additional options. With the change, this becomes a lot easier.
|
|
|
|
Help and version messages can be generated using the new
fuse_lowlevel_help(), fuse_lowlevel_version(), fuse_mount_help(), and
fuse_mount_version() functions.
The fuse_parse_cmdline() function has been made more powerful
to do this automatically, and is now explicitly intended only
for low-level API users.
This is a code simplication patch. We don't have to parse for --help and
--version in quite as many places, and we no longer have a low-level
initialization function be responsible for the (super-high level) task
of printing a program usage message.
In the high-level API, we can now handle the command line parsing
earlier and avoid running other initialization code if we're just going
to abort later on.
|
|
Also, do not include "General options" in usage message.
|
|
The only struct fuse_chan that's accessible to the user application is
the "master" channel that is returned by fuse_mount and stored in struct
fuse_session.
When using the multi-threaded main loop with the "clone_fd" option, each
worker thread gets its own struct fuse_chan. However, none of these are
available to the user application, nor do they hold references to struct
fuse_session (the pointer is always null).
Therefore, any presence of struct fuse_chan can be removed
without loss of functionality by relying on struct fuse_session instead.
This reduces the number of API functions and removes a potential source
of confusion (since the new API no longer looks as if it might be
possible to add multiple channels to one session, or to share one
channel between multiple sessions).
Fixes issue #17.
|
|
|
|
|
|
Mounting a FUSE file system remotely using SSH in combination with
pseudo-terminal allocation (-t), results in "Transport endpoint is
not connected" errors when trying to access the file system contents.
For example:
# ssh -t root@localhost "cmsfs-fuse /dev/disk/by-path/ccw-0.0.0190 /CMSFS"
Connection to localhost closed.
# ls /CMSFS
ls: cannot access '/CMSFS': Transport endpoint is not connected
The cmsfs-fuse main program (which can also be any other FUSE file
system) calls into the fuse_main() libfuse library function.
The fuse_main() function later calls fuse_daemonize() to fork the
daemon process to handle the FUSE file system I/O.
The fuse_daemonize() function calls fork() as usual. The child
proceeds with setsid() and then redirecting its file descriptors
to /dev/null etc. The parent process, simply exits.
The child's functions and the parent's exit creates a subtle race.
This is seen with an SSH connection. The SSH command above calls
cmsfs-fuse on an allocated pseudo-terminal device (-t option).
If the parent exits, SSH receives the command completion and closes
the connection, that means, it closes the master side of the
pseudo-terminal. This causes a HUP signal being sent to the process
group on the pseudo-terminal. At this point in time, the child might
not have completed the setsid() call and, hence, becomes terminated.
Note that fuse daemon sets up its signal handlers after fuse_daemonize()
has completed.
Even if the child has the chance to disassociate from its parent process
group to become it's own process group with setsid(), the child still
has the pseudo-terminal opened as stdin, stdout, and stderr. So the
pseudo-terminal still behave as controlling terminal and might cause a
SIGHUP at closing the the master side.
To solve the problem, the parent has to wait until the child (the fuse
daemon process) has completed its processing, that means, has become
its own process group with setsid() and closed any file descriptors
pointing to the pseudo-terminal.
Closes: #27
Reported-by: Ofer Baruch <oferba@il.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
|
|
|
|
|
|
Returns the full PACKAGE_VERSION string, per autoconf
|
|
New functions: fuse_chan_get(), fuse_chan_put(). Removed function:
fuse_chan_destroy().
|
|
|
|
There's actually just one type of channel and session, so we don't need the
generic callback functions.
|
|
Replace fuse_session_next_chan() with fuse_session_chan(), as multiple
channels per session were never actually supported and probably never will.
|
|
- fuse_kern_unmount closes handle (e.g. 19)
- a thread in my process opens a file - the OS assigns newly freed
handle (i.e. 19)
- fuse_kern_chan_destroy closes the same handle (i.e. 19)
- a thread in my process opens another file - the OS assigns newly
freed handle (i.e. 19)
- * MAYHEM *
Reported by Dan Greenfield
|
|
|
|
for consistency.
Reported by Vladimir Rutsky
|
|
|
|
|
|
|
|
daemon() is a BSD-ism. Although it is available on many platforms
it is not a standard function. Some platforms (e.g. MacOSX) deprecated
it.
It is safer just to use fork() function that is a part of POSIX.
|
|
|
|
The bulk of it is just about adding ifdef __NetBSD__ where there is
already an ifdef __FreeBSD__
Add a arch=netbsd to deal with NetBSD specifics. I suggests that
arch=bsd could be renamed to arch=freebsd
NetBSD specific linking with -lperfuse
NetBSD patches to lib/mount.c. It turned to be less itrusive to patch
mount;c than mount_bsd.c. I suggest mount_bsd.c could be renamed to
mount_freebsd.c
Patch from Emmanuel Dreyfus
|
|
|
|
|
|
|
|
|
|
|
