mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1550] Firefox no longer works after update--works again when downgraded #1031
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#1031
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 @rieje on GitHub (Sep 14, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1550
I'm on Arch Linux and updated firejail to 0.9.50 (along with the rest of the system) and
firejail /usr/bin/firefoxresults in a Firefox that no longer connects to the internet. I downgraded firejail back to 0.9.48 and I no longer have this issue. Tell me what info you guys need. My firefox.profile.@SkewedZeppelin commented on GitHub (Sep 15, 2017):
In Firefox could you go to "Preferences > Advanced > Network > Connection > Settings" and check "No proxy" and see if that makes a difference?
And to confirm that is Firefox 55 yes?
Edit: Also can you replace your ~/.config/firejail/firefox.profile with this one and see if it helps?
@rieje commented on GitHub (Sep 15, 2017):
I checked "No proxy" and also tried the posted firefox.profile but neither solved the issue. I am on Firefox 55.
@Fred-Barclay commented on GitHub (Sep 15, 2017):
Has your system been fully updated (except for firejail)?
@rieje commented on GitHub (Sep 15, 2017):
I had already updated my system including firejail, then found the latest firejail to have the problem described, so I downgraded just the firejail package while the rest of the system is still updated on Arch.
@eomanis commented on GitHub (Sep 15, 2017):
I have been hit by this as well, neither Firefox nor Pidgin in its own --private= home directory can access the internet with firejail-0.9.50-1, but a downgrade to firejail-0.9.48-1 fixed it.
I guess I'll pin the package to the good version with IgnorePkg = firejail in /etc/pacman.conf for the time being.
@netblue30 commented on GitHub (Sep 15, 2017):
The fix is in git, or so is believed.
There were two other reports: https://github.com/netblue30/firejail/issues/1531 and https://github.com/netblue30/firejail/issues/1547. Remove or comment out (add a #) "blacklist /var/lib/systemd" line in /etc/firejal/disable-common.inc. This is the merge:
1e879f1199Try it out, if this fixes it for you I'll do a new release by the end of the month.
@eomanis commented on GitHub (Sep 15, 2017):
@netblue30 Commenting out "blacklist /var/lib/systemd" does not solve the issue for me, but it does seem that #1547 is spot on and not having DNS resolution if done by systemd-resolved is the culprit, because my sandboxes cannot access the target of the /etc/resolv.conf symlink with firejail-0.9.50-1, however they can do so with firejail-0.9.48-1.
Please note that on Arch, if systemd-resolved is used, /etc/resolv.conf symlinks to /run/systemd/resolve/resolv.conf, and not anywhere below /var/lib/systemd.
I grepped everything in /etc/firejail and looked into my own stuff in ~/.config/firejail, and I could not find any blacklist directive for /run that would explain why the sandboxes cannot access /run/systemd/resolve/resolv.conf, and that weirds me out a bit.
@edit Uh, sorry, my bad. It appears that systemd-resolved creates a dynamic resolv.conf in both
/run/systemd/resolve
and in
/var/run/systemd/resolve.
I'll symlink /etc/resolv.conf to the one in /var and see if that helps.
(I don't see where /var/lib/systemd comes into play at all here though)
@eomanis commented on GitHub (Sep 15, 2017):
Okay now, what worked for me was this (assuming you use systemd-resolved):
make sure that /etc/resolv.conf links to /var/run/systemd/resolve/resolv.conf (and not to /run/systemd/resolve/resolv.conf)Does not matter, both work, see @netblue30's explanation below@netblue30 I suspect when you suggested to comment out the blacklisting directive for "/var/lib/systemd" you actually meant "var/run/systemd"?
@netblue30 commented on GitHub (Sep 15, 2017):
Yes, I meant "/var/run/systemd".
/var/lib/systemd is still blacklisted. The code is here: https://github.com/netblue30/firejail/blob/master/etc/disable-common.inc#L81, one line below is the blacklist to /var/run/systemd commented out. I think this fixes the problem.
/run and /var/run are the same thing - /var/run is a symlink to /run.