flatpak-spawn: Unable to read struct signalfd_siginfo: Bad file descriptor

[monreal]

Linux distribution and version

Fedora 34 beta

Flatpak version

1.10.2

Description of the problem

I use the flatpak of Pika backup. When I needed to check something on the command line I realized I do not have borgbackup installed on my client. So I tried using borg from the flatpak. It seems to work fine but I get multiple warnings from flatpak-spawn like this:

** (flatpak-spawn:6): WARNING **: 16:05:29.483: Unable to read struct signalfd_siginfo: Bad file descriptor

** (flatpak-spawn:6): WARNING **: 16:05:29.483: Unable to read struct signalfd_siginfo: Bad file descriptor

** (flatpak-spawn:6): WARNING **: 16:05:29.483: Unable to read struct signalfd_siginfo: Bad file descriptor

Steps to reproduce

1. use Pika to create a backup at ssh://user@server:/~/backup
2. alias borg='flatpak run --command=borg org.gnome.World.PikaBackup'
3. borg mount user@server:/~/backup ~/borg

[tinywrkb]

IIUC it's borg -> python-llfuse -> libfuse.so -> /bin/fusermount. fusermount is setuid binary so forget about running it from the sandbox, it won't work.
What might work is replacing fusermount with a flatpak-spawn wrapper.

This is what I'm doing to get rclone mount working. I took the wrapper from Builder but added a test to make sure that the value _FUSE_COMMFD not one of the hardcoded FDs.

There's a short explanation about fusermount here and for more details you gonna need to read the code.

[monreal]

fusermount is setuid binary so forget about running it from the sandbox, it won't work.

Well the thing is it does seem to work fine. Without the warning message I would not have guessed there is a problem at all.

[tinywrkb]

It only works because the app adds a flatpak-spwan wrapper. This sounds like something that should be reported to the maintainers of the Flatpak packaging of the app.

[smcv]

This could be a bug in either https://github.com/flatpak/flatpak-xdg-utils (the implementation of flatpak-spawn), or the fusermount-wrapper.sh in https://github.com/flathub/org.gnome.World.PikaBackup, or both. Either way, probably not a Flatpak bug as such.

@sophie-h, please could you take a look at this from the org.gnome.World.PikaBackup side?

I think what's going on here might be that fusermount-wrapper.sh is hard-coded to forward fds 1, 2 and 3 to the fusermount command that is run on the host, but there's no guarantee that fd 3 is open (strictly speaking there's no guarantee that fds 1 and 2 are open either, but they're stdout and stderr, so they really should be). If fd 3 is not already open, when flatpak-spawn opens a new fd to handle signals, it might be given fd 3 to use for that - but then the code that handles --forward-fd will close fd 3, making the signalfd processing fail.

If I'm right, then a solution in PikaBackup would look something like this (totally untested!):

-exec flatpak-spawn --host --forward-fd=1 --forward-fd=2 --forward-fd=3 $FD_ARGS fusermount "$@"
+if [ -e /proc/self/fd/3 ] && [ 3 != "$_FUSE_COMMFD" ]; then
+    FD_ARGS="$FD_ARGS --forward-fd=3"
+fi
+
+exec flatpak-spawn --host --forward-fd=1 --forward-fd=2 $FD_ARGS fusermount "$@"

[smcv]

Oh, also, you never need to --forward-fd=1 or --forward-fd=2 explicitly, because flatpak-spawn does that by default anyway (see its source code for details). So that's definitely something that can be simplified in fusermount-wrapper.sh.

[sophie-h]

@smcv thanks so much for all the details and the potential solution! And thanks @monreal for reporting this!

Tbh I just copy pasted the script that everyone uses. Besides the warnings there are probably no other implications. I'm tracking this under https://gitlab.gnome.org/World/pika-backup/-/issues/118

If anyone else finds this issue but for another app: The identical fusermount-wrapper.sh exists in many other apps.

[sophie-h]

I have verified that 3 is the bad file descriptor. Therefore this can probably be closed.

[smcv]

Let's leave the flatpak-xdg-utils bug open until flatpak-spawn handles this more gracefully and gives a better warning (I think I can see how, I just need to write the code).

[smcv]

Besides the warnings there are probably no other implications

The other implications are: if you send a signal like SIGINT or SIGTERM to flatpak-spawn, it won't pass that signal on to fusermount like it's meant to (it might not be able to anyway, because fusermount is setuid, but it should at least try).