[GH-ISSUE #3911] firecfg breaking firejail on the command line #2454

New issue

Closed

opened 2026-05-05 09:08:21 -06:00 by gitea-mirror · 1 comment

gitea-mirror commented

2026-05-05 09:08:21 -06:00

Owner

Originally created by @smitsohu on GitHub (Jan 22, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3911

Bug and expected behavior
Running firejail application on a command line fails in certain circumstances. The problem occurs if a symbolic link to firejail was created in /usr/local/bin, for example by means of firecfg, and the sandbox is too restrictive to allow execution of a shell.

Reproduce
Steps to reproduce the behavior. Options usually come from a profile but are passed on the command line here; gedit is an arbitrary example and could be anything:

sudo ln -s /usr/bin/firejail /usr/local/bin/gedit
firejail --noprofile --private-lib --shell=none gedit or
firejail --profile=/etc/firejail/disable-shell.inc --shell=none gedit
note that private-bin rescues this, because firecfg links in /usr/local/bin are masked

Command 2 gives me

Child process initialized in 780.41 ms
Warning: an existing sandbox was detected. /usr/bin/gedit will run without any additional sandboxing features
/bin/bash: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory

Command 3 gives me

Child process initialized in 23.67 ms
Warning: an existing sandbox was detected. /usr/bin/gedit will run without any additional sandboxing features
Cannot start application: Permission denied

Additional context / proposed fix
If Firejail is run inside a Firejail sandbox (run_no_sandbox), everything it does requires a shell. Would it be acceptable to remove this dependency and take the --shell=none code path instead?

Alternatively it should also work if the sandbox process, with --shell=none configured, searches the executable in $PATH, skips all these links created by firecfg and then runs the program from an absolute path (rather than delegating the work to execvp)

Originally created by @smitsohu on GitHub (Jan 22, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/3911 **Bug and expected behavior** Running `firejail application` on a command line fails in certain circumstances. The problem occurs if a symbolic link to firejail was created in /usr/local/bin, for example by means of `firecfg`, and the sandbox is too restrictive to allow execution of a shell. **Reproduce** Steps to reproduce the behavior. Options usually come from a profile but are passed on the command line here; gedit is an arbitrary example and could be anything: 1. `sudo ln -s /usr/bin/firejail /usr/local/bin/gedit` 2. `firejail --noprofile --private-lib --shell=none gedit` or 3. `firejail --profile=/etc/firejail/disable-shell.inc --shell=none gedit` 4. note that `private-bin` rescues this, because `firecfg` links in /usr/local/bin are masked Command 2 gives me ``` Child process initialized in 780.41 ms Warning: an existing sandbox was detected. /usr/bin/gedit will run without any additional sandboxing features /bin/bash: error while loading shared libraries: libtinfo.so.6: cannot open shared object file: No such file or directory ``` Command 3 gives me ``` Child process initialized in 23.67 ms Warning: an existing sandbox was detected. /usr/bin/gedit will run without any additional sandboxing features Cannot start application: Permission denied ``` **Additional context / proposed fix** If Firejail is run inside a Firejail sandbox (run_no_sandbox), everything it does requires a shell. Would it be acceptable to remove this dependency and take the `--shell=none` code path instead? Alternatively it should also work if the sandbox process, with `--shell=none` configured, searches the executable in $PATH, skips all these links created by `firecfg` and then runs the program from an absolute path (rather than delegating the work to `execvp`)

gitea-mirror

2026-05-05 09:08:21 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 09:08:24 -06:00

Author

Owner

@smitsohu commented on GitHub (Jan 26, 2021):

Would it be acceptable to remove this dependency and take the --shell=none code path instead?

I think this way is better because programs in restrictive sandboxes would be still able to run third programs via firecfg symbolic links.

@smitsohu commented on GitHub (Jan 26, 2021): > Would it be acceptable to remove this dependency and take the --shell=none code path instead? I think this way is better because programs in restrictive sandboxes would be still able to run third programs via firecfg symbolic links.

gitea-mirror referenced this issue

2026-05-05 10:17:57 -06:00

[PR #2454] [MERGED] Harden dig.profile #4324

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#2454

No description provided.

Rows
Columns