mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #4734] Error: cannot join namespace user #2767
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#2767
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 @minus7 on GitHub (Dec 2, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4734
Description
Sending a link to open to Firefox running in firejail via
firejail --join=ff2 firefox http://localhostsometimes starts failing permanently for that target firejail with the error messageError: cannot join namespace user. I usually observe that when I open multiple links in quick succession.I have seen this happen for a long time, but very rarely (less than once a month). Looking at the call site, this seems like it's a bug in firejail but rather in the kernel. Wondering if anyone else has come across that and, like me, just hasn't posted this yet.
Steps to Reproduce
I haven't tried reproducing this with a minimal test case yet, so I'll leave my setup as reference:
Firejail is started with the following command (also used to open links, but the command provided mentioned above also fails) is used to start the firejail:
br-vpn is a bridge with a WireGuard interface attached to it. I assume most of it is irrelevant though.
Environment
Checklist
/usr/bin/vlc) "fixes" it).@rusty-snake commented on GitHub (Dec 2, 2021):
Maybe related: #4543
@minus7 commented on GitHub (Dec 2, 2021):
Unlikely, since Firefox continues working just fine, and invocations don't even get to running
firefox. On the other hand, if running firejail simultaneously can somehow lead to breaking the namespace setup, that could be a possible explanation.Joining the user namespace also fails with
nsenterwith a different message (presumably fromstrerror(3)), but unfortuantely I don't have that at hand now@minus7 commented on GitHub (Dec 2, 2021):
Inspired by https://github.com/netblue30/firejail/discussions/4538#discussioncomment-1314540, I tried reproducing it using:
and
but without success
@ghost commented on GitHub (Dec 2, 2021):
Would you mind posting your
$HOME/.dotfiles/firejail/firefox.profilehere please? If you happen to have aglobals.localand a non-defaultfirejail.configit would help to see those too, so we can try to follow/reproduce what exactly happens on your side. There are other ways to open links in a firejailed firefox, but let's try to get a clear picture of this specific issue before going there.@minus7 commented on GitHub (Dec 3, 2021):
The
firefox.profileonly hasmkdir/whitelistto add some dirs and otherwise only includes/etc/firejail/firefox.profile. I have not made any other modifications to the config (noglobals.localandfirejail.configis all commented out)@minus7 commented on GitHub (Dec 5, 2021):
Okay, it happened again and this time I compared a strace to a working instance. Relevant parts here: broken working (joining firejail's pids changed to 13337/13338 for better diffability; the primary child processes' pids are unchanged: 2715 in the broken one, 21888 in the working one)
The weird difference here is the
chroot. It fails on the working instance: Firejail tries to chroot to the root of process 21888, which is the bash child process started withfirejail --name=test […] bash. This obviously fails, since this chroot is executed after joining the PID namespace, so PID 21888 doesn't exist (or rather, it's PID 1). I'm not sure if Firejail does that on purpose or if that's a bug, but it is why strange things happen on the broken instance:Here the chroot succeeds although it shouldn't. Entering the broken firejail works with
nsenterif you don't try to join the user namespace:sudo nsenter -i/proc/2715/ns/ipc -n/proc/2715/ns/net -p/proc/2715/ns/pid -u/proc/2715/ns/uts -m/proc/2715/ns/mnt bash. Looking around there for a bit we can see the following:The outside PID, while not listed in the directory listing of /proc, is accessible (gives the expect 'No such file or directory' in the working one), and more, its root seems to be broken or inaccessible, so there's obviously not /proc/1/ns/user in there to join, which explains the
ENOENTin the strace.Looking in the broken /proc further, there's a PID 2710, which oddly seems to have the same cmdline as the 2715 ghost process (which is very odd unless firefox starts two processes with the same childID argument), but stat says it's something else:
Looks like that 2715 process just points at some garbage data, and the fact that it has the same PID as the first firefox process on the host surely isn't a coincidence.
Edit: after patching out the chroot call in firejail, it works
@rusty-snake commented on GitHub (Jun 8, 2022):
firejail 0.9.70 has improved join code, can you test if this still happens with it when it is released.
@rusty-snake commented on GitHub (Oct 30, 2022):
I'm closing here due to inactivity, please fell free to request to reopen if you still have this issue.