Allow opening hyperlinks

[ghost]

With the upcoming 0.9.72 release approaching I'm going over some profiles to check a few things that have been in my notes for a while. One of these topics is (how to) allow opening hyperlinks. Here are my observations/questions that came up in that context.

The hyperlink support functionality seems to rely on the following firejail options being present:

• access to Firefox profile info
  • noblacklist ${HOME}/.mozilla
  • whitelist ${HOME}/.mozilla/firefox/profiles.ini
  • read-only ${HOME}/.mozilla/firefox/profiles.ini
• access to the Firefox D-Bus user bus
  • dbus-user.talk org.mozilla.*
• access to a shell
  • include allow-bin-sh.inc when disable-shell.inc is present
  • bash,sh being present in private-bin when that is used

If those are indeed all needed I think we should double-check/test our profiles that currently have support for opening hyperlinks. The list below includes a request for checking/confirming this functionality, adressed at the original creators of the profile.

balsa.profile @kortewegdevries commit

• include allow-bin-sh.inc is missing
• bash,sh missing from private-bin
• dbus-user.talk org.mozilla.* is not mentioned in the D-Bus section

kube.profile @kortewegdevries commit

• include allow-bin-sh.inc is missing
• bash,sh missing from private-bin
• dbus-user.talk org.mozilla.* is not mentioned in the D-Bus section

telegram.profile @BaderSZ commit

• access to Firefox profile info is missing
  • noblacklist ${HOME}/.mozilla
  • whitelist ${HOME}/.mozilla/firefox/profiles.ini
  • read-only ${HOME}/.mozilla/firefox/profiles.ini

trojita @kortewegdevries commit

• include allow-bin-sh.inc is missing
• bash,sh missing from private-bin
• dbus-user.talk org.mozilla.* is not mentioned in the D-Bus section

zeal.profile @rusty-snake commit

• include allow-bin-sh.inc is missing
• bash,sh missing from private-bin

Although the original profile creators have been referenced, anyone who can confirm the hyperlink functionality in the above profiles is working as expected is asked to give a shout.

I've already opened PR's for profiles I created/use daily and which needed fixes. Feel free to comment on those as well:

• profiles: email: allow pinentry and opening links in Firefox via dbus #5564
• profiles: geary: allow opening hyperlinks via dbus #5565

Let's get this all in shape for 0.9.72, TIA!

Relates to:

• [meta] Opening links outside of the sandbox #6462

[rusty-snake]

@bbhtt see OP.

---

IMHO we should fix the "Firejail URL open game" (#5364) instead of adding level 1 hack to more profiles and keep maintaining it working.

[rusty-snake]

I made a 0.1.0 release of fireurl: https://github.com/rusty-snake/fireurl/releases/tag/v0.1.0

[ghost]

Nice work on the static binaries! In the mean time I went over our profiles and counted only 10 profiles that have 'level 1 hack' support at the time of writing. They all happen to include wurc so porting them to support fireurl would be a breeze. Not every app we have profiles for would need the hyperlink functionality anyway. I have everything needed to prep a PR for that.

My only remaining question is why don't we add these two small executables to contrib (together with the fireurld systemd unit) and make life easy for firejail package maintainers? Adding a classic fireurld.desktop XDG-autostart file for both systemd/non-systemd OS'es is another option:

$ cat /etc/xdg/autostart/fireurld.desktop
[Desktop Entry]
Name=FireURL Daemon
Comment=Open hyperlinks between Firejail sandboxes via UNIX domain socket
Exec=fireurld
Icon=fireurld
StartupNotify=false
Type=Application

NoDisplay=true
X-GNOME-HiddenUnderSystemd=true
X-GNOME-UsesNotifications=false
X-systemd-skip=true

Maybe I'm over-simplifying this fireurl integration into firejail. That would be a decision both @netblue30 and you need to agree upon I guess...

[rusty-snake]

Maybe I'm over-simplifying this fireurl integration into firejail.

Just shipping fireurl with firejail is simple. If you however want to integrate fireurl into firejail by starting fireurld if it is not running and mounting the socket at e.g. /run/firejail/fireurl.sock i.e. making fireurl always working w/o profile changes or anything else, requires more work.

[ghost]

If you however want to integrate fireurl into firejail by starting fireurld if it is not running and mounting the socket at e.g. /run/firejail/fireurl.sock

Sure. One more fireurl.desktop file, placed in /usr/share/applications for example and (informing the user about) setting that as the default web browser should do it correct? I'm pretty sure package managers can deal with all this.

$ cat /usr/share/applications/fireurl.desktop
[Desktop Entry]
Name=FireURL Client
Comment=Open hyperlinks between Firejail sandboxes via UNIX domain socket
Exec=fireurl %U
Icon=fireurld
Type=Application
Categories=Network;WebBrowser;

MimeType=text/html;x-scheme-handler/http;x-scheme-handler/https;

[ghost]

To clarify my opinion: pushing for a solution to be 100% ready for the upcoming 0.9.72 is not what's important. Ofcourse we need to think this through and have an open discussion on. That being said, the recurring questions/issues about this functionality go back years. Sometimes one needs to break a few eggs if one wants to make an omelet...

[chrisgoldberg1]

Has Fireurl made it into Firejail now, or how many more years will this annoying issue actually remain a problem? How do you deal with situations like opening links in Telegram or Thunderbird? Do we really still have to copy and paste links in 2025 when using Firejail? I've encountered this issue several times and always searched for a solution, but it seems there's no proper solution that doesn't involve significant "hacks."