mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #5010] firefox: cannot make new connections after switching network connection methods (resolv.conf) #2856
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#2856
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 @alexdelorenzo on GitHub (Mar 5, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5010
Description
After using Firefox for a bit on WiFi and then experiencing a network failure, when I go to change my network connection method to Ethernet, I cannot open or refresh pages in Firefox.
Connections will time out and I'll have to close the browser and open it again in order to load or refresh pages.
Steps to Reproduce
Open Firefox with Firejail, let it run for a bit. After experiencing a network connection error, change your connection via a separate network device. Go back to Firefox and try to open "google.com".
Expected behavior
I should be able to resume using the browser after experiencing a network failure and/or network device change.
Actual behavior
After network failure/network device change, trying to open new pages or refreshing tabs results in those tabs eventually timing out without loading. The browser must exit and start again for it to work.
Behavior without a profile
This does not seem to be an error with Firejail-less Chromium or when I've tried to replicate the issue in Firefox without Firejail.
Additional context
Environment
Checklist
/usr/bin/vlc) "fixes" it).https://github.com/netblue30/firejail/issues/1139)browser-allow-drm yes/browser-disable-u2f noinfirejail.configto allow DRM/U2F in browsers.--profile=PROFILENAMEto set the right profile. (Only relevant for AppImages)Log
Output of
LC_ALL=C firejail /path/to/programOutput of
LC_ALL=C firejail --debug /path/to/program@rusty-snake commented on GitHub (Mar 5, 2022):
Does it work if you enter a ip address in the urlbar?
https://1.1.1.1/for examplei.e. is this a DNS problem or a network problem.
@JMillz269 commented on GitHub (Mar 5, 2022):
I have a very similar (maybe same?) issue. Running "firejail firefox" has no internet connection but "firejail --noprofile firefox" does have internet. Entering that IP address in the urlbar does load a page and works as well.
@rusty-snake commented on GitHub (Mar 5, 2022):
If you use openSUSE: #4954
@JMillz269 commented on GitHub (Mar 5, 2022):
I use Arch with networkd, not openSUSE. But the fix listed there worked. Whitelisted /etc/resolv.conf and all is well. Thanks!
@rusty-snake commented on GitHub (Mar 5, 2022):
Where does your /etc/resolv.conf point to? We should whitelist that path too.
@JMillz269 commented on GitHub (Mar 5, 2022):
It points to /run/systemd/resolve/stub-resolv.conf. This is already in the whitelist file.
@e-pirate commented on GitHub (Mar 6, 2022):
I'm having same problem after updating from firejail-0.9.64.4 to firejail-0.9.68.
If FF is running inside new firejail-0.9.68 it will not connect anywhere if network changes (after reconnecting to a different WiFi network for example). If I start VPN, all resources will not be accessible for FF. After restarting FF (still inside firejail-0.9.68) while connected to a "new" network/VPN, FF will start working as usual. Besides I have some corporate messengers running inside firejail to prevent them from doing nasty things and firejail-0.9.68 do not affect messengers - they will continue to work after connecting to "new" network and without restarting. Seems that this issue affect only FF. Besides, I can definitely confirm that this issue appeared after firejail update and affects all versions of FF I have.
I tested FF running without firejail and connecting to different networks make no effect on FF, it will continue to work.
I checked me update logs and confirmed what I suspected - firejail was updated recently. So I rolled back to 0.9.64 and all problems gone. Now FF having no problems after network reconnection. All configs are same.
To draw the line: this seems firejail-0.9.68 problem related to FF only.
@rusty-snake commented on GitHub (Mar 6, 2022):
@e-pirate https://github.com/netblue30/firejail/issues/5010#issuecomment-1059726947
@e-pirate commented on GitHub (Mar 7, 2022):
@rusty-snake https://1.1.1.1 is accessible with 0.9.68 while other sites by their names are not. Looks like a DNS problem.
@rusty-snake commented on GitHub (Mar 7, 2022):
Which distro do you use? Which program manages your DNS config? Where does you
/etc/resolv.confpoint to? Do you use nss_dns or nss_resolve first?@alexdelorenzo commented on GitHub (Mar 8, 2022):
I'll let you know if it happens again or if I'm able to replicate it. I don't remember exactly, but I do have some vague memory of trying to access a machine on my network at
10.0.4.1and it not working, but I could be wrong.@e-pirate commented on GitHub (Mar 8, 2022):
Gentoo. I believe that NetworkManager is handling my DNS configuration. resolv.conf point to correct set of DNS servers all the time.
I can confirm, that the problem affects only FF and only with firejail version 0.9.68.
@rusty-snake commented on GitHub (Mar 8, 2022):
If this happens, can you still open
file:///etc/resolv.confin a new tab? Does it work if you enable DoH in firefox?@fuine commented on GitHub (Mar 9, 2022):
I can reproduce this bug on Arch with FF and firejail version 0.9.68. Downgrading to 0.9.64.4 solves the issue. In my case I can open
file:///etc/resolv.confin a tab. With 0.9.68 the content of this file doesn't change in firefox after changing the network, even though the file changes on disk. So from FFs point of view the file never changes and so the dns setup is wrong. Version 0.9.64 works as expected, that is the content offile:///etc/resolv.confchanges accordingly to the actual/etc/resolv.conf@alexdelorenzo commented on GitHub (Mar 10, 2022):
I encountered this bug again, and was able to load pages via IP addresses. I didn't check
/etc/resolv.conf, but what @fuine describes would explain the behavior that I experienced.The DNS servers that are set for my first network configuration are only available on that network, and I switched to a second connection where I couldn't reach them.
/etc/resolv.confremaining the same between network changes from Firefox's view would do that.@rusty-snake commented on GitHub (Mar 10, 2022):
As a workaround it should work with
@rusty-snake commented on GitHub (Mar 10, 2022):
Related: #3649
edit: and #1889
@e-pirate commented on GitHub (Mar 10, 2022):
BTW, I noticed an error saying "unknown option --with-whitelist" or something like this while building 0.9.68 on Gentoo. Have no clue if this related or not, just FYI.
@rusty-snake commented on GitHub (Mar 10, 2022):
00cb236add/RELNOTES (L43)cc @hlein
It's not related.
@hlein commented on GitHub (Mar 11, 2022):
Aha, yup this should be fixed in Gentoo as of a few weeks ago (https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0246df2ab9257ecb01fa6fc453a7c647cd1ca543). @e-pirate do you know if you were building
firejail-0.9.68-r1.ebuild?(If that's the version you were/are building and still see that error, please file a bug over at https://bugs.gentoo.org as it's a Gentoo packaging problem for me, not a firejail problem.)
@e-pirate commented on GitHub (Mar 12, 2022):
Nop, I was building 0.9.68, because 0.9.68-r1 is marked unstable:
But I can still build 0.9.68-r1 and return to you with the result.
@hlein commented on GitHub (Mar 12, 2022):
Hah, right! I forgot that 0.9.68 got marked stable; as a proxy maintainer that is above my pay grade ;)
Thanks!
@e-pirate commented on GitHub (Mar 12, 2022):
I can confirm that there is no errors related to
--disable-whitelistduring 0.9.68-r1 build process, but the DNS problem remains. Downgraded to 0.9.64.4 again.@hlein commented on GitHub (Mar 12, 2022):
rusty-snake wrote:
Did this workaround work for either @e-pirate or @alexdelorenzo ? Sounds like it did for JMillz269.
I can imagine some situations when it might not (generally: if the thing-managing-resolv.conf-links doesn't stick to one directory to store the pointed-to files). But I don't want to go down that rabbit hole unless confirmed we need to.
@rusty-snake commented on GitHub (Mar 12, 2022):
I say we need a general solution for resolv.conf changes (see also #3649).
@alexdelorenzo commented on GitHub (Mar 13, 2022):
No, it didn't. My
/etc/resolv.confis not a symlink, and/etcis not a valid whitelist path, as Firejail gives me this error:Instead, I added this to
~/.config/firejail/whitelist-run-common.local:After relaunching Firefox, and switching networks to one that can't reach my DNS servers, my
/etc/resolv.confdoes not change in Firefox's view.I tried the same thing with Chromium, and added the whitelist line to a
firefox.localandchromium.localfile to see if that would change anything for either app, and it doesn't.The
/etc/resolv.confan app first sees is the file that remains between network changes, while my system'sresolv.confchanges consistently.@Nils-TUD commented on GitHub (Apr 10, 2022):
As far as I can see this is a general issue and has nothing to do with the firefox profile or other profiles. When I run:
and open
file:///etc/resolv.confin firefox and then change the network, the content of theresolv.confstays the same, as far as firefox is concerned.I didn't find any workaround with 0.9.68 yet. However, downgrading to 0.9.66 solves the issue. In case it matters, I'm running on Arch and
/etc/resolv.confis no symlink in my case.@alexdelorenzo commented on GitHub (Apr 12, 2022):
@Nils-TUD, what happens when you view
/etc/resolv.conffrom another browser, like Chromium, and change it?@Nils-TUD commented on GitHub (Apr 13, 2022):
With Chromium it's exactly the same: it always shows the same content for
/etc/resolv.confalthough it changed on disk.@RalfJung commented on GitHub (Apr 13, 2022):
I am having the same problem for all my firejailed applications. (I had this problem for weeks but blamed it on the applications.) As far as I can tell, I don't even have private-etc set for these profiles. This is hard to debug since
ping,hostand so on fail to run even after I commented out the "disable-programs" include (no idea what is happening here).Adding
whitelist /etc/resolv.confdoes not help. Removingnetfilterdoes not help either.It almost looks like firejail is doing something magic with /etc/resolv.conf and there is no way to disable that?
EDIT: Ah, https://github.com/netblue30/firejail/issues/3649 explains it -- the file is replaced rather than changed by NetworkManager and somehow together with the
/etcwhitelisting that means the update is not propagated to the jail.OTOH, in my case the DNS servers actually stay the same as I switch between Wifi and cable. And yet the applications lose connectivity. So I am not sure if DNS is the only problem and routing is not also affected? (As I said, hard to debug since none of the regular networking tools seem to work inside the jail.)
@rusty-snake commented on GitHub (Apr 13, 2022):
hostisblacklisted indisable-common.incpingmay be killed bycaps.drop all,noroot,nonewprivs,seccomp,protocol, ...@hlein commented on GitHub (Apr 13, 2022):
I don't remember the mechanics used by firejail for this, but FWIW if you bind-mount a file, the mount is sticky to the inode, so if you
unlink+open(O_CREAT)orrenameto update the file, the bind-mount will still see the old one:So: if firejail uses bind-mounts or a mechanism with similar behavior, and interface-updating methods replace
/etc/resolv.confrather than rewrite it in place, then that would explain what people are seeing - stale contents in jails.if that's the case... maybe an inotify watcher on the origin file, and update the bind-mount when the origin changes inode?
@RalfJung commented on GitHub (Apr 13, 2022):
Yeah that's probably what happens.
But that doesn't explain why it only started fairly recently.
@rusty-snake commented on GitHub (Apr 13, 2022):
Maybe wrc.inc but this would not affect all program but you said all programs are affected so it must be something else. Maybe a change in NetworkManager or something else?
@RalfJung commented on GitHub (Apr 13, 2022):
Using
statI can confirm that after a network configuration change,/etc/resolv.confhas a different inode inside and outside the jail.As in, it recently started replacing the file rather than keeping the same inode? That's a possibility.
Did anyone try downgrading firejail to an earlier version to see if that fixes it?
@Nils-TUD commented on GitHub (Apr 13, 2022):
Yes, 0.9.66 still works for me.
@RalfJung commented on GitHub (Apr 13, 2022):
Next step might be to bisect the git history then? I have never tried building firejail from source, but with "virtually no dependencies" I guess that won't be too hard.
@Nils-TUD commented on GitHub (Apr 14, 2022):
Yes, was indeed easy, I just did the bisect:
@rusty-snake commented on GitHub (Apr 14, 2022):
ba9c9699e7firejail --noprofile --blacklist=/etc/passwd ls -l /etc/passwd -> ENOENTblacklistsemantic./etc/my-deamon.confsudo firejail --noprofile --writable-etc --blacklist=/etc/nanorc touch /etc/1234 && ls /etc/1234 => ENOENT@RalfJung commented on GitHub (Apr 17, 2022):
Now I wonder what the security benefits of
ba9c9699e7are. Is there any chance of making that behavior opt-in (or at least opt-out)?All I really want from firejail is an easy way to configure which part of the file system an application can access, but increasingly, firejail is getting extra 'smart' features that are super hard to debug when they break something.
@RalfJung commented on GitHub (Jun 3, 2022):
Cc @netblue30 (author of that commit) -- is there any chance to have a release of firejail with the problematic commit reverted, that clearly had unintended consequences?
Right now I have to manually restart all my sandboxed applications twice a day, or they lose connectivity. (Which for most of them, makes them useless.) This is the kind of experience that makes one consider just giving up on sandboxing entirely. I will probably have to resort to a local build of firejail that reverts the buggy commit.
@rusty-snake commented on GitHub (Jun 3, 2022):
As workarounds you can also change your NetworkManager/systemd-networkd/... settings or use firejail's
dnscommand. See https://github.com/netblue30/firejail/issues/5171#issuecomment-1142340548.And yes, the next release should at least contain a hotfix.
But IMHO we need special resov.conf handling anyway #3649, #1889, #4954, #5171.
@RalfJung commented on GitHub (Jun 3, 2022):
Ah, good to know, thanks. I can see the
dnscommand.However, I don't understand what the suggested configuration change to NetworkManager is. Looks like /etc/resolv.conf needs to become a symlink somehow?
For now I just got my local build of firejail with that commit reverted to work.
@rusty-snake commented on GitHub (Jun 3, 2022):
The file/symlink is special for 5171, it was more generally about change resolv.conf handling by NM. I've for example set
rc-manager=unmanagedinNetworkManager.conf(i.e. NM does to touch my/etc/resolv.conf) together with a static/etc/resolv.confpointing to my local dnsmasq which is setup to block trackers/ads/malware/..., cache, validated dnssec, prevent dns rebinding and gets its upstream nameservers from/run/NetworkManager/no-stub-resolv.conf. As a result/etc/resolv.confnever changes.@DatAres37 commented on GitHub (Sep 6, 2022):
So not to sound rude or anything, but I hope you guys realize that this is currently a big issue for VPN users. I noticed this yesterday by accident: Run firejailed Firefox or Element -> activate VPN (for example Wireguard through NetworkManager) -> Your whole DNS traffic gets leaked to your standard DNS. This is especially a problem for users with a higher threat level and it makes me a bit worried how long this issue is already open without some users realizing it.
@ghost commented on GitHub (Sep 6, 2022):
@DatAres37 Marking this as a bug. Hopefully that will bring this back to the attention of our devs. Thanks for your comment & patience!
@covex commented on GitHub (Nov 4, 2022):
Found the same issue lately - the VPN changes to resolve.conf (NM manged) are not used in firejailed firefox.
Upgrade firejail-0.9.70-1.fc35.x86_64 @updates
Upgraded firejail-0.9.66-2.fc35.x86_64 @@System
Is there any solution for this - I did not found anything clear in this issue..
@rusty-snake commented on GitHub (Nov 4, 2022):
@covex https://github.com/netblue30/firejail/issues/5010#issuecomment-1145869131
@covex commented on GitHub (Nov 4, 2022):
Hm, thanks, so it looks like I have to reconfigure NM and start local dns server to workaround a problem in firejail, right? Seems easier to downgrade the firejail...
@rusty-snake commented on GitHub (Nov 4, 2022):
Downgrade to a vulnerable version ?! 😨
If the specific cause on your system was introduced with 0.9.70,
ignoreeverything that causes this (depends on your DNS setup). My comment works generally as it is a working universal DNS setup.@RalfJung commented on GitHub (Nov 4, 2022):
I still think
ba9c9699e7should be reverted or at least be made opt-out, it just breaks too many things...At https://github.com/RalfJung/firejail I have a version of 0.9.68 with the problematic patch reverted. Sadly that doesn't apply cleanly on 0.9.70 any more.
@gfarrell commented on GitHub (Dec 20, 2022):
I've seen that there is a release candidate for 0.9.72, but that doesn't appear to contain a fix for this bug, which is currently preventing firefox working when I use my VPN (mullvad over wireguard) -- I have to kill and reopen firefox whenever my laptop sleeps or there there are any network changes.
Is there a plan to include a fix for this in 0.9.72?
@rusty-snake commented on GitHub (Dec 20, 2022):
A fix is unlikely since nobody worked on it yet and it will be a lot work. Mitigations/Workarounds however should be considered.
ba9c9699e7@gfarrell commented on GitHub (Dec 20, 2022):
I don't know the inner workings of firejail at all, but perhaps reverting
ba9c969is the best bet for the 0.9.72 release then? That seems like it would balance the work required with the gains of repairing the problematic behaviour.@gfarrell commented on GitHub (Feb 3, 2023):
I was very excited about 0.9.72 landing so that I could go back to using my VPN, but unfortunately it appears that this has not fixed the issue described here. I have recorded a screen recording demonstrating the behaviour in case that's useful.
In my firejail.conf I have
etc-hide-blacklisted no(as is now default anyway). The only thing in my firefox.local is a whitelist for mutt's email output so I can see emails in a browser.@rusty-snake commented on GitHub (Feb 3, 2023):
ba9c9699e7(first release 0.9.70) is fixed now.@e-pirate commented on GitHub (Feb 5, 2023):
Can you please make clear is 0.9.72 will work for NM managed VPNs?
UPD: updated to 0.9.72 and nop, Firefox still not working after connecting to a different wifi with same symptom - DNS servers are not updated. Bummer.
@kmk3 commented on GitHub (Feb 5, 2023):
As mentioned by @rusty-snake, the original issue ("can't make new
connections after switching network methods") seems to have been fixed as of
0.9.72.
The issue with NetworkManager and VPNs might be related, but it is not the same
issue.
Please open a dedicated bug report for it so that it can be properly tracked:
@vinc17fr commented on GitHub (Jun 3, 2025):
In the Debian bug 1010569, there is a comment saying that this issue resurfaced with 0.9.74 when private-etc was enabled. I can confirm that a change in
/etc/resolv.confis not propagated.@aurelf commented on GitHub (Jun 13, 2025):
Same here on Arch.
@kmk3 commented on GitHub (Jun 14, 2025):
This is likely the same issue as:
See also: