[GH-ISSUE #3612] join-or-start can break #2266

New issue

Closed

opened 2026-05-05 08:57:41 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

2026-05-05 08:57:41 -06:00

Owner

Originally created by @smitsohu on GitHub (Aug 29, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3612

Bug and expected behavior
It is possible to run in a situation where join and join-or-start fail with Error: no valid sandbox even though the specified pid or the specified sandbox name is valid. This is a problem for applications like Okular that join-or-start by default.

Reproduce
Steps to reproduce the behavior:

firejail --join-or-start=bla
In a second terminal firejail --join-or-start=bla
exit the first sandbox
In a third terminal firejail --join-or-start=bla

Background
A situation is created where the sandbox that is to be joined contains a Firejail leaf in the process tree:

me@here:~> firejail --tree
3004:me:okular:firejail okular 
  3005:me::firejail okular  <-- Firejail leaf
3036:me::firejail okular 
  3037:me::okular

Code in join.c detects this issue and causes Firejail to die:
80fddd3163/src/firejail/join.c (L338)

Fortunately this code is (kind of) obsoleted by the introduction of RUN_SECCOMP_LIST and also by f74fa71cf9 and 89fa2a7562.

A fix should be easy, I'll send one later today or tomorrow, along with some smaller improvements.

Originally created by @smitsohu on GitHub (Aug 29, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3612 **Bug and expected behavior** It is possible to run in a situation where `join` and `join-or-start` fail with `Error: no valid sandbox` even though the specified pid or the specified sandbox name is valid. This is a problem for applications like Okular that `join-or-start` by default. **Reproduce** Steps to reproduce the behavior: 1. `firejail --join-or-start=bla` 2. In a second terminal `firejail --join-or-start=bla` 3. `exit` the _first_ sandbox 4. In a third terminal `firejail --join-or-start=bla` **Background** A situation is created where the sandbox that is to be joined contains a Firejail leaf in the process tree: ``` me@here:~> firejail --tree 3004:me:okular:firejail okular 3005:me::firejail okular <-- Firejail leaf 3036:me::firejail okular 3037:me::okular ``` Code in join.c detects this issue and causes Firejail to die: https://github.com/netblue30/firejail/blob/80fddd316359ee03c12e01ea9b34fbf3073584c1/src/firejail/join.c#L338 Fortunately this code is (kind of) obsoleted by the introduction of RUN_SECCOMP_LIST and also by f74fa71cf9d549b1607ca5b0c9fb2442e31f72ab and 89fa2a7562e84338d88ea83777861f00e545135d. A fix should be easy, I'll send one later today or tomorrow, along with some smaller improvements.

gitea-mirror

2026-05-05 08:57:41 -06:00

closed this issue
added the
bug
label

gitea-mirror referenced this issue

2026-05-05 10:16:28 -06:00

[PR #2266] [MERGED] Consistency fixes for alias profiles #4243

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#2266

No description provided.

Rows
Columns