Execution with flatpak

[bersace]

General information. Describe your environment

• Versions
  • Operating system: Debian GNU/Linux 10 (buster)
  • Browser: 76.0b3, mozilla-flatpak 1.0
  • PassFF: 1.9.1
  • Host app: pass 1.7.3

Status line output: [15:27:05] ls -> (-1) PassFF failed to execute the host app

---

Actual behaviour

Right after installation of passff in FF-flatpak, the extension shows an error about connecting to host app.

Expected behaviour

I expect to have a way for passff to have access to host pass even through flatpak.

Steps to reproduce the behaviour

1. Install mozilla-flatpak (official)
2. Install passFF

[bersace]

Would it be possible to use SecretService freedesktop API instead of a host app ?

Anyway, passff works great outside flatpak.

[bersace]

Or maybe use another web API on top of pass.

[tuxor1337]

Related upstream: https://bugzilla.mozilla.org/show_bug.cgi?id=1621763

In the meantime, maybe somebody can adapt this howto: https://discourse.flathub.org/t/how-to-run-firefox-and-keepassxc-in-a-flatpak-and-get-the-keepassxc-browser-add-on-to-work/437?u=rugk ...?

[Danacus]

I investigated this issue and tried to do something similar to the solution for keepassxc.

I wanted to avoid using flatpak-spawn, but I quickly realised that might not be possible unless someone wrote an application that runs on the host and listens for messages on a socket that it will then pass on to pass.

Here is what I did:

1. I copied passff.py and passff.json to /home/<user>/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts
2. Then I edited passff.json by setting path to /home/<user>/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/passff.py

I then tried copying pass and tree to /home/<user>/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts and setting COMMAND = "/home/<user>/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/pass" in passff.py. I then gave org.mozilla.firefox access to ~/.password-store and ~/.gnupg using flatseal or flatpak-override.

While this seemed to work at first, I was unable to decrypt any passwords as if passff was unable to show me a dialog to unlock my GnuPG key. At this point I realised this probably wasn't going to work and I would have to use the "ugly" solution instead. So I continued with the following steps.

3. I edited the following line in passff.py:

Replace

cmd = [COMMAND] + opt_args + ['--'] + pos_args

with

cmd = ["flatpak-spawn", "--host", "/usr/bin/pass"] + opt_args + ['--'] + pos_args

4. In order to allow the flatpak to run a program on the host system you need to allow Firefox to talk to org.freedesktop.Flatpak on the session bus. This can be configured with flatseal or by using flatpak override --talk-name=org.freedesktop.Flatpak org.mozilla.firefox.

And that's it! passff should work perfectly fine in flatpak Firefox.

The only real downside is that this completely breaks the sandbox and allows programs within the Firefox flatpak sandbox to execute any program on the host system.

I think that until the native messaging interface is replaced with a more flatpak-friendly alternative, it might be better to write an application that runs on the host and listens for messages on a socket. This application would then pass on these messages to pass. Then passff.py could be replaced by a program that sends messages to this socket. The advantage of this approach is that we could simply allow the flatpak to communicate through this socket without having to break the sandbox.

[Randalix]

Is there a more convenient solution for this by now?

[tuxor1337]

This is actually a duplicate of https://github.com/passff/passff-host/issues/56 Sorry, I didn't notice since this one is in passff/passff while the other issue is in passff/passff-host.

[xundeenergie]

I investigated this issue and tried to do something similar to the solution for keepassxc.

I wanted to avoid using flatpak-spawn, but I quickly realised that might not be possible unless someone wrote an application that runs on the host and listens for messages on a socket that it will then pass on to pass.

Here is what I did:

1. I copied `passff.py` and `passff.json` to `/home/<user>/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts`

2. Then I edited `passff.json` by setting `path` to `/home/<user>/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/passff.py`

I then tried copying pass and tree to /home/<user>/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts and setting COMMAND = "/home/<user>/.var/app/org.mozilla.firefox/.mozilla/native-messaging-hosts/pass" in passff.py. I then gave org.mozilla.firefox access to ~/.password-store and ~/.gnupg using flatseal or flatpak-override.

While this seemed to work at first, I was unable to decrypt any passwords as if passff was unable to show me a dialog to unlock my GnuPG key. At this point I realised this probably wasn't going to work and I would have to use the "ugly" solution instead. So I continued with the following steps.

3. I edited the following line in `passff.py`:

Replace

cmd = [COMMAND] + opt_args + ['--'] + pos_args

with

cmd = ["flatpak-spawn", "--host", "/usr/bin/pass"] + opt_args + ['--'] + pos_args

4. In order to allow the flatpak to run a program on the host system you need to allow Firefox to talk to `org.freedesktop.Flatpak` on the session bus. This can be configured with flatseal or by using `flatpak override --talk-name=org.freedesktop.Flatpak org.mozilla.firefox`.

And that's it! passff should work perfectly fine in flatpak Firefox.

The only real downside is that this completely breaks the sandbox and allows programs within the Firefox flatpak sandbox to execute any program on the host system.

I think that until the native messaging interface is replaced with a more flatpak-friendly alternative, it might be better to write an application that runs on the host and listens for messages on a socket. This application would then pass on these messages to pass. Then passff.py could be replaced by a program that sends messages to this socket. The advantage of this approach is that we could simply allow the flatpak to communicate through this socket without having to break the sandbox.

You can let pass and tree on it's original place, if you change the desktop-file for flatpak.

Copy the file cp /var/lib/flatpak/app/org.mozilla.firefox/current/active/export/share/applications/org.mozilla.firefox.desktop ~/.local/share/applications/org.mozilla.firefox.desktop and change the the "Exec" lines

for example: Exec=/usr/bin/flatpak run --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.firefox --new-window @@u %u @@ to Exec=/usr/bin/flatpak run --filesystem=/usr/bin/pass --filesystem=/usr/bin/tree --branch=stable --arch=x86_64 --command=firefox --file-forwarding org.mozilla.firefox --new-window @@u %u @@

Add --filesystem=/usr/bin/pass --filesystem=/usr/bin/tree to every Exec-Line after the "run"

[oktayacikalin]

The last combination works fine for me on Fedora 38 with Firefox in flatpak. At least after I added the line in session bus in flatseal.