to have the right user/group ids by default (no need to provide uid/gid, simple autofs config files that work for everybody)
to use the/my user rclone config automatically
to have more control on the rclone executable
for security reasons
And if it can work my guess is that it should probably be the default, I can see no downside except in a multi-user setting.
For that, I tried messing with the rclone mount helper scripts (rclonefs, mount.rclone), adding a rclone_user argument, and using su or sudo to run rclone but with no success so far:
if [[ ! -z "$USER" ]]; then
log "running mount under user $USER"
#sudo -u $USER $RCLONE mount --daemon $args "$remote" "$mountpoint" </dev/null >/dev/null 2>&1
#exec su $USER -c "$RCLONE mount --daemon $args "$remote" "$mountpoint" </dev/null >/dev/null 2>&1"
su $USER -c "$RCLONE mount --daemon $args "$remote" "$mountpoint" </dev/null >/dev/null 2>&1"
#su $USER -c "rclone mount --allow-non-empty --allow-other --log-file /var/log/rclonefs.log --verbose rebex: /tmp/mnt/ &"
else
log "running mount using current user" $(id)
exec $RCLONE mount --daemon $args "$remote" "$mountpoint" </dev/null >/dev/null 2>&1
fi
I believe the assumption that uid/gid of the fuse process providing a filesystem will be inherited by the mount is false.
Please note that mount is a service provided by the kernel deeply interconnected with the VFS kernel subsystem.
The classic flow is:
external data (eg. NFS or CIFS) -> kernel -> mount
The relatively new FUSE flow (in particular, rclone) is:
external data -> FUSE program eg. rclone (user space) -> libfuse -> FUSE module (kernel) -> kernel VFS -> mount
Normally libfuse/modfuse will set mount permissions in the kernel from uid/gid parameters submitted by the fuse program.
rclone takes them from the same named CLI arguments since most cloud storages do not have a direct equivalent.
OTOH being a mount provider is a privileged operation. Kernel will not allow anyone to form parts of its filesystem (mounts) due to high security risks.
Bottomline. Even if you find a hack to run mount.rclone as a non-root user via some ad-hoc setting under your Autonountd or with help of setcap, it's not gonna do what you expect.
Thank you for your timely and very thorough answer.
I'm not sure to understand it all.
What I really don't understand is that when you just run rclone mount remote: mountpoint using your normal user everything works fine right ? Without using any privilege or capability, everything happening in userspace.
Fair enough.
I wasn't 100% thorough so let's fill the gap
rclone uses libfuse/gofuse to create mounts, which invokes helper program fusermount passing it dedicated mount options.
The program is "suid-root" so it has the mount capability:
deex@vesta:~$ ls -l /bin/fusermount
-rwsr-xr-x 1 root root 39144 Mar 7 2020 /bin/fusermount
deex@vesta:~$
As a tradeoff for giving a non-root user the ability to mount it will perform a number of restricting checks explained in fuse docs. See FUSE — The Linux Kernel documentation
The corrected flowchart is:
external data -> FUSE program eg. rclone (user space, non-root) -> libfuse -> fusermount (user space, root) -> FUSE module (kernel) -> kernel VFS -> mount
Yet the most critical stuff takes place in the kernel. Notice how different is the control of the mounted fs permissions from direct process uid/gid inheriting...
Ok, that makes more sense now, thank you.
What could be useful is an autofs/mount.rclone option, such as user=joe that would set:
uid and gid to the user id and primary group id
config (if not given) to ~user/.config/rclone/rclone.conf
Still, looking at the doc, there's this:
Non-privileged mount (or user mount):
A userspace filesystem mounted by a non-privileged (non-root) user. The filesystem daemon is running with the privileges of the mounting user. NOTE: this is not the same as mounts allowed with the “user” option in /etc/fstab, which is not discussed here.
So they say that the fs daemon is running with the privileges of the mounting user. But in our case,using autofs,the mounting user is root,isn't it ?
Another problem with Automount (classic automountd or newer systemd) is that it does not provide a way to run mount unit as a non-root user or set any environment variables including PATH or HOME for mount programs.
When rclone is run normally, it will use HOME to derive location of cache and rclone.conf and perform tilde ~ expansion in some settings. It's not possible when rclone runs under Automount so user should at least explicitly submit --config and --cache-dir options as absolute paths.
the actual mount is always performed as root (either directly or via the suided fusermount)
but the filesystem daemon itself runs as a normal user in the normal rclone mount case, and as root when using autofs
executing the filesystem daemon as root is less secure and has a number of annoyances (ids mapping, config/cache paths, ...)
That makes me think that if we could, as I tried, run rclone mount as normal user with autofs it could be a win/win.
What I tried was to run the rclone command as my user using su/sudo. It failed but I have no clue why.
Could you provide me some hints on what could be the problem ?
I can't help here as I never used fuse with sudo.
Just can't wrap my head around such a complex chain of uid-gid-capability transformations: sudo -> suid -> fuse. It resembles a card tower and may have security consequences IMO.
Also I don't like the fact that a system-wide mount service shares config/cache with interactive user sessions.
I'd use it in a classic straightforward way: owned by root with statically set config/cache paths and explicit uid/gid mountpoint permissions.
Automount support is a brand new rclone feature yet. I'd rather wait until next release so it jumps into wilderness of use cases, let user bug reports settle, then plan next steps.
You can continue your experiments to your taste. I can just recommend to look deeper into sudo flags and check whether HOME is set for the prefixed program or whether shell profile is applied affecting your mount. Also you can look at the systemd user mode.
