Mark H Weaver <firstname.lastname@example.org> skribis:
Toggle quote (16 lines)
> Claes Wallin (韋嘉誠) <email@example.com> writes:
>> On 27-Jul-2015 5:06 pm, "Andreas Enge" <firstname.lastname@example.org> wrote:
>>> when trying to execute sshfs from the sshfs-fuse package, I obtain
>>> fuse: failed to exec fusermount: No such file or directory
>>> I think that fuse should be a propagated input of sshfs-fuse.
>> Maybe it's less intrusive toward the user to wrap sshfs to add fuse to
>> its PATH?
> Or patch the reference to 'fusermount' to be an absolute path?
This what libfuse does by default in lib/mount.c:
Toggle snippet (7 lines)
static void exec_fusermount(const char *argv)
execv(FUSERMOUNT_DIR "/" FUSERMOUNT_PROG, (char **) argv);
execvp(FUSERMOUNT_PROG, (char **) argv);
However, we explicitly patch it because in practice the ‘fusermount’
binary must be at least set-user-gid to fuse, per mount.fuse(8):
Toggle snippet (9 lines)
;; This hack leads libfuse to search for 'fusermount' in
;; $PATH, where it may find a setuid-root binary, instead of
;; trying solely $out/sbin/fusermount and failing because
;; it's not setuid.
On GuixSD, this is addressed by having ‘fusermount’ setuid-root in
/run/setuid-programs, so things just work.
On foreign distros, there’s not much we can do: Users have to set add a
setuid ‘fusermount’ in their PATH.
Closing this bug as “wontfix.”