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).

[PrzemekSkw]

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 "$@"

Hello, I want to restore backup from my remote local server but have Bad descriptor error. Can You explain me how that arguments above can fix that?
Regards.

[sophie-h]

Hello, I want to restore backup from my remote local server but have Bad descriptor error. Can You explain me how that arguments above can fix that?

This is completely unrelated to this issue. I have posted a workaround here https://gitlab.gnome.org/World/pika-backup/-/issues/613#note_2519762

The relevant Ubuntu issue is here https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/2120439

[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).

Better late than never: #71 fixes the confusing symptom.

The original issue reported here was a PikaBackup bug (now fixed afaics) rather than a flatpak-spawn bug. If other apps exhibit similar output, the solution is to fix their flatpak-spawn invocation so that it only forwards the correct fd (for example the $_FUSE_COMMFD), and not other, unrelated fds.