search

flatpak / flatpak-xdg-utils

Simple portal-based commandline tools for use inside flatpak sandboxes
GNU Lesser General Public License v2.1
32 stars 14 forks source link

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

Open monreal opened 3 years ago

monreal commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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

smcv commented 3 years ago

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 commented 3 years ago

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