Mark H Weaver <mhw@netris.org> skribis:
Toggle quote (16 lines)
> Claes Wallin (韋嘉誠) <gnu@clacke.user.lysator.liu.se> writes:
>
>> On 27-Jul-2015 5:06 pm, "Andreas Enge" <andreas@enge.fr> wrote:
>>>
>>> Hello,
>>>
>>> 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.
(substitute* "lib/Makefile"
(("-DFUSERMOUNT_DIR=[[:graph:]]+")
"-DFUSERMOUNT_DIR=\\\"/var/empty\\\""))
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.”
Ludo’.
