mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4670] firefox: cannot open new URLs into running instance #2744
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#2744
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Lonniebiz on GitHub (Nov 6, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4670
Firejail version: 0.9.62
Kubuntu 20.04 recently auto-updated to Firefox 94. Ever since, I can no longer launch URLs via the command line like this:
firejail firefox https://github.com &I posted this issue over at AskUbuntu :
https://askubuntu.com/questions/1373963/
Actually, it will launch fine if Firefox is completely closed, but none of my hot keys that launch additional pages work anymore.
This may not be a firejail bug, but I was hoping that posting here might lead to me finding a good work around. Please check out the link above. I appreciate it!
@kmk3 commented on GitHub (Nov 6, 2021):
@Lonniebiz commented on Nov 6:
Please follow the bug template:
Does it help if both invocations use the same sandbox? Example:
@Lonniebiz commented on GitHub (Nov 7, 2021):
firejail version 0.9.62
Kubuntu 20.04
Firefox 94.0
@kmk3 First of all, I really appreciate your attention to the matter. This issue (no matter what is causing it) is pretty important to my workflow. You see, I'm accustom to launching websites I frequent with hotkeys facilitated by autokey.
So, I'm not typing these commands in directly, it is a python script within autokey that is sending the commands to the terminal. That script is only two lines:
However, for the test you've requested, I'm going to copy and pasted those lines (one at a time) directly into the terminal:
Result: The first line launched the browser like normal. However, when I entered the second command, I got this error:
Output:
@Lonniebiz commented on GitHub (Nov 7, 2021):
Submitted to Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=1739919
@kmk3 commented on GitHub (Nov 8, 2021):
@Lonniebiz commented on Nov 7:
That version is old and potentially vulnerable to 3 CVEs; see:
There is more to the template than the environment section and I don't feel
like copy pasting parts of it here.
The generic advice would be to try commenting parts of the relevant profiles to
narrow down the issue.
Other than that, there are a few similar-looking issues that may be of help:
@rusty-snake commented on GitHub (Nov 8, 2021):
Does firefox 64 use the (native) Wayland backend? (context #3290)
@RolKau commented on GitHub (Nov 9, 2021):
I had this exact problem using Firefox 94 under Ubuntu Focal 20.04. Firejail 0.9.62 is the version in the Ubuntu repository. Upgrading to Firejail 0.9.66 (through using the 'deki' PPA) seems to have fixed it.
@ibhagwan commented on GitHub (Nov 16, 2021):
I'm having a similar issue, Firefox 94.0 and firejail 0.9.66:
Resulting in the below popup inside firefox:
@RolKau commented on GitHub (Nov 18, 2021):
@ibhagwan
Where do your Firejail profiles come from? For me, they are in a companion package named
firejail-profilesthat I also had to upgrade (if you are on a Debian-derivative system you can for instance see which version you have with a command likeapt-cache policy $(dpkg -S /etc/firejail/firefox.profile | cut -d: -f1))@ibhagwan commented on GitHub (Nov 18, 2021):
@RolKau, my profiles came with the default
firejailpackage on void linux:@RolKau commented on GitHub (Nov 19, 2021):
The profiles that are in the Void Linux repository are from this repository, and they match the ones that I have on my installation (from the 'deki' PPA) exactly, so that rules them out as the culprit.
@RolKau commented on GitHub (Nov 19, 2021):
The options and version from
firejail --versionare the same, except that my version has the option "SELinux support is enabled" whereas yours (@ibhagwan, that is) has "SELinux support is disabled". I am not qualified to say if that is relevant.@Lonniebiz commented on GitHub (Dec 13, 2021):
Debian 11 Stable
firejail-profiles version 0.9.64.4-2
@RolKau I'm having the exact same problem again, now with LibreWolf.
@oo-san commented on GitHub (Dec 17, 2021):
You must be using an old firefox profile. I encountered the same erorr, but it works when using the firefox profile bundled with the latest release of firejail (0.9.66).
Adding
ignore dbus-user noneto an older profile also fixed this problem for me.@ibhagwan commented on GitHub (Dec 17, 2021):
Unfortuntely that's not the case, I have firejail 0.9.66 and my firefox commands includes
--dbus-user=none:@ghost commented on GitHub (Dec 17, 2021):
@ibhagwan By using
--dbus-user=nonein a shell script or on the command line you are breaking thelogicof our firefox profiles (aka @oo-san is correct). Let me explain. Firefox uses D-Bus to open URLs in a running instance (instead of starting a second one). Firejail takes this into account in two steps. To tighten the sandbox we first disallow access to both user and system bus by havingdbus-user noneanddbus-system nonein firefox-common.profile. To keep things like URL processing working in a reasonable way we grant access only to a very limited and specific subset of options. Have a look inside your firefox.profile. Near the bottom you'll see:The first four lines define that we want to grant access to these specific adressess on the user bus only). The
ignore dbus-user nonejust before the redirect is needed to compensate fully disabling all D-Bus access from inside the sandbox. I hope this clears things up a bit. What happens when you use the below in your shell script?@ibhagwan commented on GitHub (Dec 17, 2021):
@glitsj16 tysm for the explnation, it does help clear things up a bit.
I just tried running without the
--dbus-user=noneand then ran the following command:And this is what I get inside firefox (basically same result):
@ghost commented on GitHub (Dec 18, 2021):
@ibhagwan I don't have a straightforward do-this-and-it-will-work answer to your issue at the moment. IMO your firejail profiles are fine and you should keep avoiding --dbus-user=none as explained above. Two remarks for further consideration.
Error: Can't find profile directorymessages are a bit unusual (at least to me). I assume your Firefox profile(s) setup is something you've already checked, but to rule this out you could do a quick test with a clean FF copy.MOZ_DBUS_REMOTE=1to the mix. See this short but very informative page from Firefox Guru Martin Stransky's blog. Either add--env=MOZ_DBUS_REMOTE=1on the command line/in your shell script or setenv MOZ_DBUS_REMOTE=1in a firefox.local override file. Shouldn't take long to see if that does anything positive.@ibhagwan commented on GitHub (Dec 18, 2021):
I will try that.
Not using wayland, X11/AwesomeWM straight forward setup.
It's worth noting the same setup worked for a long time and then one day stopped working, I can't pinpoint whether it was a firefox update or firejail update that caused this, since then I switched my
xdg-openconfig to open in ungoogled-chromium instead which is also firejailed and works fine.@ghost commented on GitHub (Dec 18, 2021):
@ibhagwan Thanks for informing us on your specific setup. I do recognize what you describe. The feeling of noticing something broke and not being able to pinpoint stuff. Been there many times, and it keeps happening, no matter how many things one keeps logs of :-). If no one tunes in here with the 'magic bullet' fix and you'd like to return to Firefox in your xdg-open, you could check if firejail-handler-http suits your needs. I wrote these shell scripts specifically to run Firefox in a firejail sandbox with
full blocking of D-Busbefore we integrated xdg-dbus-proxy into Firejail. They still work okay, if one can live with the usability/workflow impact...@Lonniebiz commented on GitHub (Dec 18, 2021):
Firejail, please fix this same issue as it pertains to the LibreWolf version 95 AppImage also.
@cockytrumpet commented on GitHub (Dec 30, 2021):
does it work if you change your script to
I think I'm getting the behavior you are looking for. I don't know how to set this up in KDE, but maybe you can translate my gnome setup to your use.
~/.local/share/applications/Firejail-Firefox.desktop
~/bin/firefox.sh
Set Firejail-Firefox as the default application. xdg-open and right clicking a link in the terminal both work.
@Druco commented on GitHub (Jan 13, 2022):
---------- EDITTED --------:
Sorry about being an idiot, but I forgot that I had made a custom profile for Thunderbird that added the following lines:
With the "dbus-user filter" line commented out, it works with FF95. Even so, it did work with FF93 even with these lines included, so something did happen between FF93 and FF95.
---------- END EDIT ----------
I am adding this here rather than opening a new bug report because I think it is pretty clearly the same problem.
Description
Attempting to open a URL in Firefox 95 from a link in an email message in Thunderbird causes the same error message as described above (Firefox is already running, but is not responding...) when Firefox and Thunderbird are in sand boxes. Running the identical setup with Firefox 93 works properly so something has changed between FF93 and FF95.
Steps to reproduce
Expected behavior
The link opens in the existing firefox instance
Actual behavior
Error message stating "Firefox is already running, but is not responding..."
Environment
OpenSuse Tumbleweed 20220109
Firejail 0.9.66
Firefox 95.02
Thunderbird 91.4.1
Behavior without a profile
Starting Firefox without a profile does not fix the problem, however starting Thunderbird without a profile does. As noted above however, if using Firefox 93 rather than Firefox 95 and the same Thunderbird, both with the same firejail profiles, everything works properly.
Checklist
Notes
sendToFirefox95FromFirejail.txt
sendToFirefox93FromFirejail.txt
@Druco commented on GitHub (Jan 14, 2022):
As a followup to my above comment, I have found a "fix"/kludge that works at least for now in my setup. Using wireshark to monitor the dbus when firefox and thunderbird were started both with and without firejail, I discovered that when a link was being opened from thunderbird it makes an OpenURL() call with a destination of "org.mozilla.firefox.ZGVmYXVsdA__" so I tried putting:
dbus-user.talk org.mozilla.firefox.ZGVmYXVsdA__in my local firejail/thunderbird.profile and it worked with firejail.
Now I have no idea where the "ZGVmYXVsdA__" comes from, if it will remain constant across upgrades, or would be different for another user/machine, but for now it works.
I also did a wireshark monitor when using FF 93 (which works without the kludge) and I didn't find this call being made. In fact, I have no idea how FF 93 even got the URL it opened because I couldn't find it in any of the dbus messages in that case. So there was definitely a change between FF 93 and FF 95.
Hopefully this might give a hint to anyone who has a similar problem and more knowledge of dbus messaging than I do.
@ghost commented on GitHub (Jan 14, 2022):
You can use globbing to make things persistent:
dbus-user.talk org.mozilla.firefox.*@rusty-snake commented on GitHub (Jan 14, 2022):
Did you set
dbus-user filter? Or where does it come from?EDIT: just saw your edit above.
It's the hash of your profile (and possible firefox installation).
System-V-IPC / X11-Magic
Traditionally FF used System-V-IPC/X11-Magic for it's IPC but this does not work with Wayland (
MOZ_ENABLE_WAYLAND=1), that's why mozilla implemented an D-Bus based backed for FF's IPC (the are more backend like for windows). Maybe they cleand up the old code and now use always D-Bus.@Lonniebiz commented on GitHub (Feb 2, 2022):
@RolKau If you have time, please take a look at this related issue.
@ibhagwan commented on GitHub (Feb 2, 2022):
Not really sure why the old versions of firefox were able to open links properly even with
--dbus-user=nonebut after the explantion from @glitsj16 I started exploring the dbus angle and after reading #3769 I was able to solve this by removing--dbus-user=noneand making sure that I have$DBUS_SESSION_BUS_ADDRESSproperly set.My dbus socket was located in
~/.dbus/session-bus/LONG-IDbut I had two files there named<ID>-0and<ID>-1(0being the correct session file) so I added the below to my firefox firejail starting script and now I can open links again in FF: