[GH-ISSUE #3434] Default shell is guessed from $SHELL, despite manpage specifying /bin/bash

gitea-mirror commented

2026-05-05 08:50:07 -06:00

Owner

Originally created by @iltep64 on GitHub (May 26, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3434

Bug and expected behavior
Firejail's man page describes the default shell for execution as /bin/bash.
However, if the given command line contains bash-isms(?) such as adding -- in firejail -- ls, and an incompatible shell is currently used and present in $SHELL (e.g. fish), then the command fails.

This issue was encountered in the zoom-firejail AUR package.

Steps and Output
The logs are collapsed for brevity.

Unexpected
The external shell environment has $SHELL=/bin/fish set, unless stated otherwise.

Running without any flags

$ export SHELL=/bin/fish
$ firejail -- ls
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 143487, child pid 143488
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Child process initialized in 32.74 ms
fish: Unknown command: --
fish: 
--
^

Parent is shutting down, bye...

Running with --noprofile

 firejail --noprofile -- ls
Parent pid 145677, child pid 145678
Child process initialized in 7.24 ms
fish: Unknown command: --
fish: 
--
^

Parent is shutting down, bye...

Expected

Direct execution

$ which ls
/usr/bin/ls
$ /usr/bin/ls
a  b  c

With firejail + a workaround, other than the command line itself, the results of execution are the same.

Running with SHELL=/bin/fish and --shell=none flag

$ firejail --shell=none -- ls
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 143496, child pid 143497
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Child process initialized in 36.39 ms
a  b  c

Parent is shutting down, bye...

Running with SHELL=/bin/fish and --shell=/bin/bash flag

$ firejail --shell=/bin/bash -- ls
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 143502, child pid 143503
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Child process initialized in 34.15 ms
a  b  c

Parent is shutting down, bye...

Running with SHELL=/bin/bash (with SHELL=/bin/fish in the external environment)

$ SHELL=/bin/bash firejail -- ls
Reading profile /etc/firejail/default.profile
Reading profile /etc/firejail/disable-common.inc
Reading profile /etc/firejail/disable-passwdmgr.inc
Reading profile /etc/firejail/disable-programs.inc

** Note: you can use --noprofile to disable default.profile **

Parent pid 143507, child pid 143508
Warning: /sbin directory link was not blacklisted
Warning: /usr/sbin directory link was not blacklisted
Child process initialized in 28.83 ms
a  b  c

Parent is shutting down, bye...

Environment

Distro: Arch Linux, using official firejail-0.9.62-1 package.
No other programs interact with /usr/bin/ls, nor has it a profile. Only bash,fish,ls, and firejail are used.

$ uname -a
Linux -HOSTNAME REDACTED- 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux
$ firejail --version
firejail version 0.9.62

Compile time support:
	- AppArmor support is enabled
	- AppImage support is enabled
	- chroot support is enabled
	- file and directory whitelisting support is enabled
	- file transfer support is enabled
	- firetunnel support is enabled
	- networking support is enabled
	- overlayfs support is enabled
	- private-home support is enabled
	- seccomp-bpf support is enabled
	- user namespace support is enabled
	- X11 sandboxing support is enabled

Checklist

The upstream profile (and redirect profile if exists) have no changes fixing it.
- No profile was provided, or manually created for /bin/ls.
The upstream profile exists.
- /bin/ls does not have a profile.
Programs needed for interaction are listed.
Error was checked in search engine and on issue list without success.
- Github issue search for $SHELL and fish returned nothing.

Workarounds

As seen in the last 3 examples, forcing either the $SHELL environment variable or the --shell flag makes it work.

Possible causes

This is the relevant line of manpage documentation:

63c44c7743/src/man/firejail.txt (L2274)

From a cursory search in the code, guess_shell() reads the environment here:

63c44c7743/src/firejail/main.c (L906)

This seems like the reason why fish is launched, and so it errors out on the -- argument separator.

EDIT: Fixed markdown to follow bug report template better.

Originally created by @iltep64 on GitHub (May 26, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3434 **Bug and expected behavior** Firejail's man page describes the default shell for execution as `/bin/bash`. However, if the given command line contains bash-isms(?) such as adding `--` in `firejail -- ls`, and an incompatible shell is currently used and present in `$SHELL` (e.g. fish), then the command fails. This issue was encountered in the `zoom-firejail` AUR package. **Steps and Output** The logs are collapsed for brevity. *Unexpected* The external shell environment has `$SHELL=/bin/fish` set, unless stated otherwise. <details> <summary>Running without any flags</summary> ``` $ export SHELL=/bin/fish $ firejail -- ls Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 143487, child pid 143488 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Child process initialized in 32.74 ms fish: Unknown command: -- fish: -- ^ Parent is shutting down, bye... ``` </details> <details> <summary>Running with <code>--noprofile</code></summary> ``` firejail --noprofile -- ls Parent pid 145677, child pid 145678 Child process initialized in 7.24 ms fish: Unknown command: -- fish: -- ^ Parent is shutting down, bye... ``` </details> *Expected* <details> <summary>Direct execution</summary> ``` $ which ls /usr/bin/ls $ /usr/bin/ls a b c ``` </details> With `firejail` + a workaround, other than the command line itself, the results of execution are the same. <details> <summary>Running with <code>SHELL=/bin/fish</code> and <code>--shell=none</code> flag</summary> ``` $ firejail --shell=none -- ls Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 143496, child pid 143497 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Child process initialized in 36.39 ms a b c Parent is shutting down, bye... ``` </details> <details> <summary>Running with <code>SHELL=/bin/fish</code> and <code>--shell=/bin/bash</code> flag</summary> ``` $ firejail --shell=/bin/bash -- ls Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 143502, child pid 143503 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Child process initialized in 34.15 ms a b c Parent is shutting down, bye... ``` </details> <details> <summary>Running with <code>SHELL=/bin/bash</code> (with <code>SHELL=/bin/fish</code> in the external environment)</summary> ``` $ SHELL=/bin/bash firejail -- ls Reading profile /etc/firejail/default.profile Reading profile /etc/firejail/disable-common.inc Reading profile /etc/firejail/disable-passwdmgr.inc Reading profile /etc/firejail/disable-programs.inc ** Note: you can use --noprofile to disable default.profile ** Parent pid 143507, child pid 143508 Warning: /sbin directory link was not blacklisted Warning: /usr/sbin directory link was not blacklisted Child process initialized in 28.83 ms a b c Parent is shutting down, bye... ``` </details> **Environment** - Distro: Arch Linux, using official `firejail-0.9.62-1` package. - No other programs interact with `/usr/bin/ls`, nor has it a profile. Only `bash`,`fish`,`ls`, and `firejail` are used. ``` $ uname -a Linux -HOSTNAME REDACTED- 5.6.13-arch1-1 #1 SMP PREEMPT Thu, 14 May 2020 06:52:53 +0000 x86_64 GNU/Linux $ firejail --version firejail version 0.9.62 Compile time support: - AppArmor support is enabled - AppImage support is enabled - chroot support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - firetunnel support is enabled - networking support is enabled - overlayfs support is enabled - private-home support is enabled - seccomp-bpf support is enabled - user namespace support is enabled - X11 sandboxing support is enabled ``` **Checklist** - [ ] The upstream profile (and redirect profile if exists) have no changes fixing it. - No profile was provided, or manually created for `/bin/ls`. - [ ] The upstream profile exists. - `/bin/ls` does not have a profile. - [x] Programs needed for interaction are listed. - [x] Error was checked in search engine and on issue list without success. - Github issue search for `$SHELL` and `fish` returned nothing. **Workarounds** As seen in the last 3 examples, forcing either the `$SHELL` environment variable or the `--shell` flag makes it work. **Possible causes** This is the relevant line of manpage documentation: https://github.com/netblue30/firejail/blob/63c44c77434f8b9175728f7891f0852eabccdd2a/src/man/firejail.txt#L2274 From a cursory search in the code, `guess_shell()` reads the environment here: https://github.com/netblue30/firejail/blob/63c44c77434f8b9175728f7891f0852eabccdd2a/src/firejail/main.c#L906 This seems like the reason why `fish` is launched, and so it errors out on the `--` argument separator. EDIT: Fixed markdown to follow bug report template better.

gitea-mirror

2026-05-05 08:50:07 -06:00

closed this issue
added the
bug
label

gitea-mirror commented

2026-05-05 08:50:10 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 27, 2020):

I'd rather ask why does firejail pass the -- to the command.

In general I recommend to use bash as login shell many program in the world tend to odd behaviour without it. In addition, non-posix shells such as fish can lead to security issues. If you want an other interactive shell, you can set it in the preferences of you terminal-emulator.

@rusty-snake commented on GitHub (May 27, 2020): I'd rather ask why does firejail pass the `--` to the command. ---- In general I recommend to use bash as login shell many program in the world tend to odd behaviour without it. In addition, non-posix shells such as fish can lead to security issues. If you want an other interactive shell, you can set it in the preferences of you terminal-emulator.

gitea-mirror commented

2026-05-05 08:50:11 -06:00

Author

Owner

@iltep64 commented on GitHub (May 27, 2020):

IMO this is at least a documentation inconsistency. Do you think updating the manpage to note the guessing behaviour would be an acceptable resolution? Though mandating bash as login shell feels a bit too opinionated. Another possibility would be to avoid guessing from $SHELL at all, and just check for bash or sh.

@iltep64 commented on GitHub (May 27, 2020): IMO this is at least a documentation inconsistency. Do you think updating the manpage to note the guessing behaviour would be an acceptable resolution? Though mandating bash as login shell feels a bit too opinionated. Another possibility would be to avoid guessing from `$SHELL` at all, and just check for `bash` or `sh`.

gitea-mirror commented

2026-05-05 08:50:12 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 27, 2020):

The manpage should be fixed, sure. But IMHO we shouldn't pass -- to the command we start.

@rusty-snake commented on GitHub (May 27, 2020): The manpage should be fixed, sure. But IMHO we shouldn't pass `--` to the command we start.

gitea-mirror commented

2026-05-05 08:50:14 -06:00

Author

Owner

@iltep64 commented on GitHub (May 27, 2020):

I looked through the code again, and I think I found the cause of the extra --.

In the argument parser in main.c, if firejail finds -- in argv, it sets arg_doubledash.
28c099bdc3/src/firejail/main.c (L2587)

Then, in sandbox.c, when building the arguments for the shell, if arg_doubledash is set, then after the initial -c arg, -- is added.
35ac39ee55/src/firejail/sandbox.c (L576)
The git blame trail for that line of logic goes cold after 1379851360 though.

EDIT: The POSIX-compliant shells (dash, zsh, ksh tested) all accept the extra --, and it does seem to be part of the POSIX standards. Perhaps the docs should specify that $SHELL should be POSIX-complaint.

Alternatively, guess_shell can compare $SHELL to a whitelist of known-good shells, and skip using it if it fails. If the user wants to force a noncompliant shell, the --shell=... option is still available.

@iltep64 commented on GitHub (May 27, 2020): I looked through the code again, and I think I found the cause of the extra `--`. In the argument parser in `main.c`, if firejail finds `--` in `argv`, it sets `arg_doubledash`. https://github.com/netblue30/firejail/blob/28c099bdc32710fc40e16aa53549a53222eef931/src/firejail/main.c#L2587 Then, in `sandbox.c`, when building the arguments for the shell, if `arg_doubledash` is set, then after the initial `-c` arg, `--` is added. https://github.com/netblue30/firejail/blob/35ac39ee55743f0a92fd67896dc122b4f225f419/src/firejail/sandbox.c#L576 The git blame trail for that line of logic goes cold after 1379851360349d6617ad32944a25ee5e2bb74fc2 though. EDIT: The POSIX-compliant shells (`dash, zsh, ksh` tested) all accept the extra `--`, and it does seem to be part of the POSIX standards. Perhaps the docs should specify that `$SHELL` should be POSIX-complaint. Alternatively, `guess_shell` can compare `$SHELL` to a whitelist of known-good shells, and skip using it if it fails. If the user wants to force a noncompliant shell, the `--shell=...` option is still available.

gitea-mirror commented

2026-05-05 08:50:15 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 4, 2020):

IMHO we should hardcode /bin/bash and maybe use $SHELL or a list ad fallback.

#3448, #2934, #2857

@rusty-snake commented on GitHub (Jun 4, 2020): IMHO we should hardcode `/bin/bash` and maybe use $SHELL or a list ad fallback. #3448, #2934, #2857

gitea-mirror commented

2026-05-05 08:50:16 -06:00

Author

Owner

@Thaodan commented on GitHub (Oct 6, 2020):

IMHO we should hardcode /bin/bash and maybe use $SHELL or a list ad fallback.

#3448, #2934, #2857

why do you request explicitly bash? There a systems without bash and unless you depend on bash features that should not be required.
But you could force to use /bin/sh as this is always installed on a POSIX system.

@Thaodan commented on GitHub (Oct 6, 2020): > IMHO we should hardcode `/bin/bash` and maybe use $SHELL or a list ad fallback. > > #3448, #2934, #2857 why do you request explicitly bash? There a systems without bash and unless you depend on bash features that should not be required. But you could force to use /bin/sh as this is always installed on a POSIX system.

gitea-mirror commented

2026-05-05 08:50:17 -06:00

Author

Owner

@ryneeverett commented on GitHub (Sep 18, 2021):

This seems particularly problematic in combination with allow-bin-sh.inc -- any program using this will break if SHELL isn't set to /bin/bash, /bin/sh, or /bin/dash.

For reference, see https://github.com/netblue30/firejail/pull/4098#discussion_r598327311:

zsh is popular as interactive shell yes, but not to write script in it as you can not assume it's installed on system. Usually you write you scripts for /bin/sh which should be present on any POSIX compatible system or /bin/bash which should be present on the most GNU/Linux systems. allow-bin-sh.inc does exactly what it names says, it allows /bin/sh. /bin/sh is a symlink to /bin/bash on the most system resp. /bin/dash on Debian/Ubuntu. Therefore they need a noblacklist too.

If this is going to be the case then firejail should just do an initial check and if SHELL isn't one of these acceptable values it should just error out.

@ryneeverett commented on GitHub (Sep 18, 2021): This seems particularly problematic in combination with `allow-bin-sh.inc` -- any program using this will break if `SHELL` isn't set to /bin/bash, /bin/sh, or /bin/dash. For reference, see https://github.com/netblue30/firejail/pull/4098#discussion_r598327311: > zsh is popular as interactive shell yes, but not to write script in it as you can not assume it's installed on system. Usually you write you scripts for `/bin/sh` which should be present on any POSIX compatible system or `/bin/bash` which should be present on the most GNU/Linux systems. `allow-bin-sh.inc` does exactly what it names says, it allows `/bin/sh`. `/bin/sh` is a symlink to `/bin/bash` on the most system resp. `/bin/dash` on Debian/Ubuntu. Therefore they need a `noblacklist` too. If this is going to be the case then firejail should just do an initial check and if `SHELL` isn't one of these acceptable values it should just error out.

gitea-mirror commented

2026-05-05 08:50:17 -06:00

Author

Owner

@kmk3 commented on GitHub (Sep 18, 2021):

@ryneeverett commented on Sep 18:

This seems particularly problematic in combination with allow-bin-sh.inc --
any program using this will break if SHELL isn't set to /bin/bash, /bin/sh,
or /bin/dash.

In the case of allow-bin-sh.inc, one way to make custom /bin/sh shells work
would be to add exceptions to ~/.config/firejail/allow-bin-sh.local or
/etc/firejail/allow-bin-sh.local:

noblacklist ${PATH}/myshell

To test it:

firejail --include=/etc/firejail/allow-bin-sh.inc \
  --include=/etc/firejail/disable-shell.inc /bin/myshell

By the way, is there any distro that ships with another shell by default?
Using a path other than /bin/bash, /bin/dash or /bin/sh?

@kmk3 commented on GitHub (Sep 18, 2021): @ryneeverett commented [on Sep 18](https://github.com/netblue30/firejail/issues/3434#issuecomment-922157662): > This seems particularly problematic in combination with `allow-bin-sh.inc` -- > any program using this will break if `SHELL` isn't set to /bin/bash, /bin/sh, > or /bin/dash. In the case of allow-bin-sh.inc, one way to make custom /bin/sh shells work would be to add exceptions to ~/.config/firejail/allow-bin-sh.local or /etc/firejail/allow-bin-sh.local: ```firejail noblacklist ${PATH}/myshell ``` To test it: ```sh firejail --include=/etc/firejail/allow-bin-sh.inc \ --include=/etc/firejail/disable-shell.inc /bin/myshell ``` By the way, is there any distro that ships with another shell by default? Using a path other than /bin/bash, /bin/dash or /bin/sh?

gitea-mirror commented

2026-05-05 08:50:18 -06:00

Author

Owner

@ryneeverett commented on GitHub (Sep 18, 2021):

I don't have any problem overriding it but ideally firejail would notify users of this issue so they don't have to track it down by process of elimination.

I'm not aware of a distro that defaults to another SHELL value. I see the relevance of this point towards what shells should go in allow-bin-sh.inc but I don't think it's an argument for maintaining the status quo. Is there any standard that says SHELL has to be one of these values?

Also, even if we accept that supporting stock distributions is the only goal, wouldn't it be simpler to hardcode /bin/sh and replace all instances of allow-bin-sh.inc with noblacklist ${PATH}/sh? What's the point of using the SHELL variable if firejail breaks if it's set to anything other than /bin/sh (or the shell /bin/sh is linked to)?

@ryneeverett commented on GitHub (Sep 18, 2021): I don't have any problem overriding it but ideally firejail would notify users of this issue so they don't have to track it down by process of elimination. I'm not aware of a distro that defaults to another SHELL value. I see the relevance of this point towards what shells should go in `allow-bin-sh.inc` but I don't think it's an argument for maintaining the status quo. Is there any standard that says SHELL has to be one of these values? Also, even if we accept that supporting stock distributions is the only goal, wouldn't it be simpler to hardcode /bin/sh and replace all instances of `allow-bin-sh.inc` with `noblacklist ${PATH}/sh`? What's the point of using the SHELL variable if firejail breaks if it's set to anything other than /bin/sh (or the shell /bin/sh is linked to)?

gitea-mirror commented

2026-05-05 08:50:18 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 19, 2021):

To say it again, allow-bin-sh.inc is only to make programs using (wrapper-)scripts with a /bin/sh (or /bin/bash) shebang work with disable-shell without the need to maintain these noblacklist in all profiles in parallel. Nobody will use anything like fish for (wrapper-)scripts.

The whole discussion about which other shells should be included in allow-bin-sh.inc is pointless.

If a distro symlinks /bin/sh to /bin/frogsh, frogsh should be included. That's the only reason to add a shell to allow-bin-sh nothing else.
If we need every possible shell inside the sandbox, we can create a allow-shells.inc with exactly the same lines as in disable-shell.inc prefixed with a no. See for yourself that this is nonsense and you just don't do include disable-shell.inc.
allow-bin-sh.inc is not the place to "include this and every shell work". There is also private-bin for example.

replace all instances of allow-bin-sh.inc with noblacklist ${PATH}/sh?

No because if /bin/sh is a symlink to a blacklisted /bin/bash it don't work, therefore we created allow-bin-sh.inc to have one point where to maintenance the necessary noblacklists for /bin/sh.

Is there any standard that says SHELL has to be one of these values?

No

@rusty-snake commented on GitHub (Sep 19, 2021): To say it again, **`allow-bin-sh.inc` is only to make programs using (wrapper-)scripts with a `/bin/sh` (or `/bin/bash`) shebang work** with `disable-shell` without the need to maintain these `noblacklist` in all profiles in parallel. Nobody will use anything like fish for (wrapper-)scripts. The whole discussion about which other shells should be included in allow-bin-sh.inc is pointless. - If a distro symlinks `/bin/sh` to `/bin/frogsh`, `frogsh` should be included. That's the only reason to add a shell to `allow-bin-sh` nothing else. - If we need every possible shell inside the sandbox, we can create a `allow-shells.inc` with exactly the same lines as in `disable-shell.inc` prefixed with a `no`. See for yourself that this is nonsense and you just don't do `include disable-shell.inc`. - allow-bin-sh.inc is not the place to "include this and every shell work". There is also `private-bin` for example. > replace all instances of allow-bin-sh.inc with noblacklist ${PATH}/sh? No because if `/bin/sh` is a symlink to a blacklisted `/bin/bash` it don't work, therefore we created `allow-bin-sh.inc` to have one point where to maintenance the necessary `noblacklist`s for `/bin/sh`. > Is there any standard that says SHELL has to be one of these values? No

gitea-mirror commented

2026-05-05 08:50:18 -06:00

Author

Owner

@ryneeverett commented on GitHub (Sep 21, 2021):

To say it again, allow-bin-sh.inc is only to make programs using (wrapper-)scripts with a /bin/sh (or /bin/bash) shebang work with disable-shell without the need to maintain these noblacklist in all profiles in parallel. Nobody will use anything like fish for (wrapper-)scripts.

Maybe that's the intent of allow-bin-sh.inc but the combined effect of these modules seems to require $SHELL to point to one of these allowed shell paths, regardless of what shell the shebang points to. For a concrete example:

$ cat bin.sh
#!/bin/sh
echo "Hello World"

$ cat bin.profile
include allow-bin-sh.inc
include disable-shell.inc

$ SHELL=/bin/sh firejail --quiet --profile=bin.profile ./bin.sh
Hello World

$ SHELL=/bin/fish firejail --quiet --profile=bin.profile ./bin.sh
Cannot start application: Permission denied

@ryneeverett commented on GitHub (Sep 21, 2021): > To say it again, **`allow-bin-sh.inc` is only to make programs using (wrapper-)scripts with a `/bin/sh` (or `/bin/bash`) shebang work** with `disable-shell` without the need to maintain these `noblacklist` in all profiles in parallel. Nobody will use anything like fish for (wrapper-)scripts. Maybe that's the intent of allow-bin-sh.inc but the combined effect of these modules seems to require $SHELL to point to one of these allowed shell paths, regardless of what shell the shebang points to. For a concrete example: ```shell $ cat bin.sh #!/bin/sh echo "Hello World" $ cat bin.profile include allow-bin-sh.inc include disable-shell.inc $ SHELL=/bin/sh firejail --quiet --profile=bin.profile ./bin.sh Hello World $ SHELL=/bin/fish firejail --quiet --profile=bin.profile ./bin.sh Cannot start application: Permission denied ```

gitea-mirror commented

2026-05-05 08:50:19 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 21, 2021):

...
$ echo "shell none" >> bin.profile
$ SHELL=/bin/sh firejail --quiet --profile=bin.profile ./bin.sh
Hello World
$ SHELL=/bin/fish firejail --quiet --profile=bin.profile ./bin.sh
Hello World

$ SHELL=/bin/sh firejail --quiet --noprofile --private-bin=blender /usr/bin/blender 
Cannot start application: No such file or directory
$ SHELL=/bin/zsh firejail --quiet --noprofile --private-bin=blender /usr/bin/blender
Cannot start application: No such file or directory
$ SHELL=/bin/sh firejail --quiet --noprofile --private-bin=blender,sh /usr/bin/blender 
Color management: using fallback mode for management
…

@rusty-snake commented on GitHub (Sep 21, 2021): ```console ... $ echo "shell none" >> bin.profile $ SHELL=/bin/sh firejail --quiet --profile=bin.profile ./bin.sh Hello World $ SHELL=/bin/fish firejail --quiet --profile=bin.profile ./bin.sh Hello World ``` ```console $ SHELL=/bin/sh firejail --quiet --noprofile --private-bin=blender /usr/bin/blender Cannot start application: No such file or directory $ SHELL=/bin/zsh firejail --quiet --noprofile --private-bin=blender /usr/bin/blender Cannot start application: No such file or directory $ SHELL=/bin/sh firejail --quiet --noprofile --private-bin=blender,sh /usr/bin/blender Color management: using fallback mode for management … ```

gitea-mirror commented

2026-05-05 08:50:19 -06:00

Author

Owner

@ryneeverett commented on GitHub (Sep 21, 2021):

My point is not that there are an insufficient number of workarounds but that there doesn't seem to be any good reason for overriding the firejail profile to be necessary. Modifying an environment variable from the distribution's default shouldn't be regarded as unconventional and, unless there's a technical reason this needs to be, shouldn't break firejailed applications.

As far as I know there's no objection to hardcoding /bin/sh rather than using $SHELL.

@ryneeverett commented on GitHub (Sep 21, 2021): My point is not that there are an insufficient number of workarounds but that there doesn't seem to be any good reason for overriding the firejail profile to be necessary. Modifying an environment variable from the distribution's default shouldn't be regarded as unconventional and, unless there's a technical reason this needs to be, shouldn't break firejailed applications. As far as I know there's no objection to hardcoding /bin/sh rather than using $SHELL.

gitea-mirror commented

2026-05-05 08:50:20 -06:00

Author

Owner

@rusty-snake commented on GitHub (Sep 21, 2021):

Why do we use a shell at all? The most profile have shell none. We could make shell none the default.

@rusty-snake commented on GitHub (Sep 21, 2021): Why do we use a shell at all? The most profile have `shell none`. We could make `shell none` the default.

gitea-mirror commented

2026-05-05 08:50:20 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 20, 2022):

shell none becomes default (#5196).

@rusty-snake commented on GitHub (Jun 20, 2022): `shell none` becomes default (#5196).

gitea-mirror referenced this issue

2026-05-05 10:15:24 -06:00

[PR #2161] [MERGED] Fix file.profile #4189

Rows
Columns

[GH-ISSUE #3434] Default shell is guessed from $SHELL, despite manpage specifying /bin/bash #2160