libfuse 3 can't find fusermount

  • Open
  • quality assurance status badge
Details
2 participants
  • Leo Famulari
  • Liliana Marie Prikler
Owner
unassigned
Submitted by
Leo Famulari
Severity
normal
L
L
Leo Famulari wrote on 21 Jan 2022 08:41
(address . bug-guix@gnu.org)
YepjvRmfZf2tNtuo@jasmine.lan
While testing a Borg update (patch attached), I noticed that the
FUSERMOUNT_DIR hack in Fuse 3 doesn't seem to work like it does with
Fuse 2.

The 1.2.0b3 beta of the upcoming Borg release can use either Fuse 2
(with python-llfuse) or Fuse 3 (with python-pyfuse3).

The `borg mount` command works as expected with Fuse 2 / llfuse.

But, with Fuse 3 / pyfuse3, it fails with:

fuse: failed to exec fusermount3: No such file or directory

When I commented out the FUSERMOUNT_DIR [0] substitution in the fuse-3
package and rebuilt Borg, `borg mount` instead gives us this, which is
expected, because this system does not have a setuid fusermount3:

fusermount3: mount failed: Operation not permitted

So, the substitution doesn't seem to help with Fuse 3: it just breaks
the lookup.

You can apply the patch and test it out. And you can also observe the
optimal behaviour if you switch the borg package's fuse implementation
from pyfuse3 to llfuse / Fuse 2.

Should we just remove the substitution in fuse-3?

[0]
Attachment: fusermount-borg.diff
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAmHqY7kACgkQJkb6MLrK
fwgRORAA2+7lXqCtOagOE5+yc0cz1/FiGpdQjMbaPkUECPnaSr5E5q1LtnSdzk9o
+ICGbSuvyy769CD8nDjz0jDBEIiOT0/jhpbmTaPIWMdGB89v3NlM7+NH9Ko6O3jU
a2ApRBJ6uN12TAkVLl35bgOFu9D+LhKwRc8NEafghh7ZQxuDio55Z+grvyDikJVX
71za6QyNnN+tNJnmKGBa3GmWJwwBED9TWnafb0clc6mG69XTBIcA6j2VMKxYEIra
BZQ0BvAYj5By+w4Mjco6SoSaqTFNQ+jSgQSNVsbVL2ips3CnDQ+Pi/UL6NElL6ZZ
OEn3i54mQotAppqZRis2gKprHqzwPofJhGGZSQgzKg+lezZz+do34IzWARC1X7e+
2Y4ULDdj2V9+pYqnFxI8R2IidcjM+KqN62UzsQPEXTptdsXCaIYBs/rzG6vPDGba
PVRGA99sHLXQMBDEFiDnsU0qSAZwfKxdWp4YL+2Y+ihztK2FN6HSSeV9EoDecdQp
JHm2x0zH7PyR1A94Wv9tjnPqHnF7B3oWcMuBPrj3uPHzOI59AU6su6sdr30tgQM8
1eiw33yMzu0CBXPW+5X2fZ+PMMToylGFyGp1lLutLwfrB/VK9o98etALDZ7WEWlP
12iGsZX+V5psw9DC1hXSfrUjsxQr6ZYG17jkc1TMLzhqNK++uEQ=
=2c8i
-----END PGP SIGNATURE-----


L
L
Liliana Marie Prikler wrote on 21 Jan 2022 08:55
f6678af305390ab15fbc25005c7642222dd08e40.camel@ist.tugraz.at
Hi Leo,

Am Freitag, dem 21.01.2022 um 02:41 -0500 schrieb Leo Famulari:
Toggle quote (27 lines)
> While testing a Borg update (patch attached), I noticed that the
> FUSERMOUNT_DIR hack in Fuse 3 doesn't seem to work like it does with
> Fuse 2.
>
> The 1.2.0b3 beta of the upcoming Borg release can use either Fuse 2
> (with python-llfuse) or Fuse 3 (with python-pyfuse3).
>
> The `borg mount` command works as expected with Fuse 2 / llfuse.
>
> But, with Fuse 3 / pyfuse3, it fails with:
>
> fuse: failed to exec fusermount3: No such file or directory
>
> When I commented out the FUSERMOUNT_DIR [0] substitution in the fuse-
> 3 package and rebuilt Borg, `borg mount` instead gives us this, which
> is expected, because this system does not have a setuid fusermount3:
>
> fusermount3: mount failed: Operation not permitted
>
> So, the substitution doesn't seem to help with Fuse 3: it just breaks
> the lookup.
>
> You can apply the patch and test it out. And you can also observe the
> optimal behaviour if you switch the borg package's fuse
> implementation from pyfuse3 to llfuse / Fuse 2.
>
> Should we just remove the substitution in fuse-3?
What is the behaviour if you have fusermount3 setuid? I know from gvfs
(which also depends on Fuse 3), that adding the setuid binary *does*
make gvfsd-fuse work again, so it'd be good to know if this works for
borg as well. If not, we'd have to be careful not to introduce a
regression.


Cheers
L
L
Leo Famulari wrote on 21 Jan 2022 18:17
(name . Liliana Marie Prikler)(address . liliana.prikler@ist.tugraz.at)(address . 53407@debbugs.gnu.org)
Yerqo2sqF0jXVD+C@jasmine.lan
On Fri, Jan 21, 2022 at 08:55:23AM +0100, Liliana Marie Prikler wrote:
Toggle quote (2 lines)
> What is the behaviour if you have fusermount3 setuid?

Then, it does work.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 53407@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 53407
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch