[GH-ISSUE #5204] Autocomplete doesn't work in bash (when firejailed)

gitea-mirror commented

2026-05-05 09:34:42 -06:00

Owner

Originally created by @denizakcal on GitHub (Jun 15, 2022).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5204

Hello. :)

To reproduce the issue, do

mkdir -p $HOME/fake_home
firejail --noprofile --private=$HOME/fake_home bash
Type "whoam" (without the quotes) (where the final character is missing on purpose) (for example) and then press tab on the keyboard. It should autocomplete to "whoami" (without the quotes).

Explanation of why I think the bug is in Firejail and not my operating system(s):
I'm 99% sure that the problem is with Firejail because I tried on various versions of (throwaway, virtual) Ubuntu systems, and if I recall correctly, versions 20.04, 20.10, 22.04 (which was using Firejail 0.9.66-2), and the in-development release of 22.10 (which was also using Firejail 0.9.66-2), did have autocomplete working in all of those (with Firejail from their respective repositories).

When I installed 0.9.70-1 from sourceforge, the bug (of autocomplete not working) was present (in more than one system).

In Debian, version 0.9.64.4-2 of Firejail in Debian stable / bullseye has autocomplete working, but versions 0.9.68-3 (if I remember correctly) and 0.9.70-1 of Firejail in Debian testing / bookworm don't have autocomplete working properly.

I would appreciate it if someone could look into this.

Let me know if more information is needed.

Originally created by @denizakcal on GitHub (Jun 15, 2022). Original GitHub issue: https://github.com/netblue30/firejail/issues/5204 Hello. :) **To reproduce the issue, do** 1. mkdir -p $HOME/fake_home 2. firejail --noprofile --private=$HOME/fake_home bash 3. Type "whoam" (without the quotes) (where the final character is missing on purpose) (for example) and then press tab on the keyboard. It should autocomplete to "whoami" (without the quotes). **Explanation of why I think the bug is in Firejail and not my operating system(s):** I'm 99% sure that the problem is with Firejail because I tried on various versions of (throwaway, virtual) Ubuntu systems, and if I recall correctly, versions 20.04, 20.10, 22.04 (which was using Firejail 0.9.66-2), and the in-development release of 22.10 (which was also using Firejail 0.9.66-2), _did_ have autocomplete working in all of those (with Firejail from their respective repositories). When I installed 0.9.70-1 from sourceforge, the bug (of autocomplete not working) was present (in more than one system). In Debian, version 0.9.64.4-2 of Firejail in Debian stable / bullseye has autocomplete working, but versions 0.9.68-3 (if I remember correctly) and 0.9.70-1 of Firejail in Debian testing / bookworm don't have autocomplete working properly. I would appreciate it if someone could look into this. Let me know if more information is needed.

gitea-mirror

2026-05-05 09:34:42 -06:00

closed this issue
added the
question_old
label

gitea-mirror commented

2026-05-05 09:34:44 -06:00

Author

Owner

@ghost commented on GitHub (Jun 15, 2022):

It's not a bug but a feature. Firejail 0.9.70 introduced a new --tab option for autocompletion support: e6c50240f9. It's in the release notes. You can put it in your globals.local (as tab) if you always want it.

@ghost commented on GitHub (Jun 15, 2022): It's not a bug but a feature. Firejail 0.9.70 introduced a new `--tab` option for autocompletion support: https://github.com/netblue30/firejail/commit/e6c50240f9f2033a896df5a06c6fc7c1529d5442. It's in the [release notes](https://github.com/netblue30/firejail/blob/master/RELNOTES#L10). You can put it in your `globals.local` (as `tab`) if you always want it.

gitea-mirror commented

2026-05-05 09:34:45 -06:00

Author

Owner

@denizakcal commented on GitHub (Jun 15, 2022):

It's not a bug but a feature. Firejail 0.9.70 introduced a new --tab option for autocompletion support: e6c5024. It's in the release notes. You can put it in your globals.local (as tab) if you always want it.

Thanks for your response, but the --tab argument seems to only fix the autocompletion with --private and not with --private=/path/to/some/directory/of/choice.

Could you please verify if that is also the behaviour exhibited on your system(s)?

@denizakcal commented on GitHub (Jun 15, 2022): > It's not a bug but a feature. Firejail 0.9.70 introduced a new `--tab` option for autocompletion support: [e6c5024](https://github.com/netblue30/firejail/commit/e6c50240f9f2033a896df5a06c6fc7c1529d5442). It's in the [release notes](https://github.com/netblue30/firejail/blob/master/RELNOTES#L10). You can put it in your `globals.local` (as `tab`) if you always want it. Thanks for your response, but the --tab argument seems to only fix the autocompletion with --private and not with --private=/path/to/some/directory/of/choice. Could you please verify if that is also the behaviour exhibited on your system(s)?

gitea-mirror commented

2026-05-05 09:34:46 -06:00

Author

Owner

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

Thanks for your response, but the --tab argument seems to only fix the autocompletion with --private and not with --private=/path/to/some/directory/of/choice.

If there is a existing $HOME/.inputrc ($HOME is your private home, $real_HOME/fake_home is your case. Firejail will not remove set disable-completion on from it. You need to remove it manually.

--tab skips the creation of a .inputrc with set disable-completion on. With --private this makes tab completion working. But with --private=foo one run w/o --tab creates inputrc which then persists in the private home.

@rusty-snake commented on GitHub (Jun 15, 2022): > Thanks for your response, but the --tab argument seems to only fix the autocompletion with --private and not with --private=/path/to/some/directory/of/choice. If there is a existing `$HOME/.inputrc` (`$HOME` is your private home, `$real_HOME/fake_home` is your case. Firejail will not remove `set disable-completion on` from it. You need to remove it manually. `--tab` skips the creation of a `.inputrc` with `set disable-completion on`. With `--private` this makes tab completion working. But with `--private=foo` one run w/o `--tab` creates `inputrc` which then persists in the private home.

gitea-mirror commented

2026-05-05 09:34:47 -06:00

Author

Owner

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

Related to #5190, why do we have this "feature" at all?

@rusty-snake commented on GitHub (Jun 15, 2022): Related to #5190, why do we have this "feature" at all?

gitea-mirror commented

2026-05-05 09:34:49 -06:00

Author

Owner

@ghost commented on GitHub (Jun 15, 2022):

Could you please verify if that is also the behaviour exhibited on your system(s)?

Here are some observations... which confirm @rusty-snake's contribution above.

[A] You're correct (--tab only works for --private, as advertised in the man page)


$ mkdir -p $HOME/fake_home

$ firejail --quiet --noprofile --private cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]
$ firejail --quiet --noprofile --private --tab cat .inputrc
cat: .inputrc: No such file or directory
$ firejail --quiet --noprofile --private --tab bash
Type "whoam" and press tab. It DOES autocomplete to "whoami". [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private=$HOME/fake_home bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]

[B] Let's try something for fun:

$ rm -rf $HOME/fake_home
$ mkdir -p $HOME/fake_home
$ firejail --quiet --noprofile --private=$HOME/fake_home echo > .inputrc


$ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc
set disable-completion on
$ firejail --quiet --noprofile --private=$HOME/fake_home bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash
Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED]

[C] Even more fun:

$ rm -rf $HOME/fake_home
$ mkdir -p $HOME/fake_home
$ echo > ~/fake_home/.inputrc


$ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc
--- no output --- [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc
--- no output --- [EXPECTED]
$ firejail --quiet --noprofile --private=$HOME/fake_home bash
Type "whoam" and press tab. It DOES autocomplete to "whoami". [NOW IT WORKS]
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash
Type "whoam" and press tab. It DOES autocomplete to "whoami". [NOW IT WORKS]

Additional testing confirmed that:

you cannot change autocompletion status of a running sandbox (with or without using options from the transfer files man page section);
if you really want/need autocompletion with --private=foo, put an empty .inputrc in the new $HOME prior to accessing it via firejail through 'regular' file system handling.

Related to #5190, why do we have this "feature" at all?

Fair question.

@ghost commented on GitHub (Jun 15, 2022): > Could you please verify if that is also the behaviour exhibited on your system(s)? Here are some observations... which confirm @rusty-snake's contribution above. [A] You're correct (--tab only works for --private, as advertised in the man page) ``` $ mkdir -p $HOME/fake_home $ firejail --quiet --noprofile --private cat .inputrc set disable-completion on $ firejail --quiet --noprofile --private bash Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED] $ firejail --quiet --noprofile --private --tab cat .inputrc cat: .inputrc: No such file or directory $ firejail --quiet --noprofile --private --tab bash Type "whoam" and press tab. It DOES autocomplete to "whoami". [EXPECTED] $ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc set disable-completion on $ firejail --quiet --noprofile --private=$HOME/fake_home bash Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED] $ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc set disable-completion on $ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED] ``` [B] Let's try something for fun: $ rm -rf $HOME/fake_home $ mkdir -p $HOME/fake_home $ firejail --quiet --noprofile --private=$HOME/fake_home echo > .inputrc ``` $ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc set disable-completion on $ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc set disable-completion on $ firejail --quiet --noprofile --private=$HOME/fake_home bash Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED] $ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash Type "whoam" and press tab. It does NOT autocomplete to "whoami". [EXPECTED] ``` [C] Even more fun: $ rm -rf $HOME/fake_home $ mkdir -p $HOME/fake_home $ echo > ~/fake_home/.inputrc ``` $ firejail --quiet --noprofile --private=$HOME/fake_home cat .inputrc --- no output --- [EXPECTED] $ firejail --quiet --noprofile --private=$HOME/fake_home --tab cat .inputrc --- no output --- [EXPECTED] $ firejail --quiet --noprofile --private=$HOME/fake_home bash Type "whoam" and press tab. It DOES autocomplete to "whoami". [NOW IT WORKS] $ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash Type "whoam" and press tab. It DOES autocomplete to "whoami". [NOW IT WORKS] ``` Additional testing confirmed that: - you cannot change autocompletion status of a running sandbox (with or without using options from the `transfer files` man page section); - if you really want/need autocompletion with --private=foo, put an empty .inputrc in the new $HOME _prior_ to accessing it via firejail through 'regular' file system handling. > Related to #5190, why do we have this "feature" at all? Fair question.

gitea-mirror commented

2026-05-05 09:34:49 -06:00

Author

Owner

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

[D]

$ rm -rf $HOME/fake_home
$ mkdir -p $HOME/fake_home
$ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash
auto-complete works

@rusty-snake commented on GitHub (Jun 15, 2022): [D] $ rm -rf $HOME/fake_home $ mkdir -p $HOME/fake_home $ firejail --quiet --noprofile --private=$HOME/fake_home --tab bash auto-complete works

gitea-mirror commented

2026-05-05 09:34:50 -06:00

Author

Owner

@denizakcal commented on GitHub (Jun 16, 2022):

Thanks! I removed the .inputrc file and used the --tab feature, and the autocomplete now works!

And, I think the feature of disabling the autocomplete by default was probably done since the autocomplete can be a security risk, as shown in this (old) Bash security bug description ( https://www.cvedetails.com/cve/CVE-2017-5932/ ), so it's probably a good thing that it is as it is, but for this particular use case of mine, I'm okay with enabling it since I have nonewprivs (and noroot) anyways*.

*I said what I said about nonewprivs (and noroot) because that bug description that I linked to was about gaining privileges, which is something that nonewprivs should prevent anyways. But, even if it were not, I feel that relying on Debian stable (for example) to have security bugs like that old Bash security bug fixed is not that big of a risk either.

To try to further justify that --tab feature, maybe a certain app would need root privileges to run, so noroot and nonewprivs would not be useful there, and one would therefore want to reduce the risk by not allowing the autocompletion in such a situation?

@denizakcal commented on GitHub (Jun 16, 2022): Thanks! I removed the .inputrc file and used the --tab feature, and the autocomplete now works! And, I think the feature of disabling the autocomplete by default was probably done since the autocomplete can be a security risk, as shown in this (old) Bash security bug description ( https://www.cvedetails.com/cve/CVE-2017-5932/ ), so it's probably a good thing that it is as it is, but for this particular use case of mine, I'm okay with enabling it since I have nonewprivs (and noroot) anyways*. *I said what I said about nonewprivs (and noroot) because that bug description that I linked to was about gaining privileges, which is something that nonewprivs should prevent anyways. But, even if it were not, I feel that relying on Debian stable (for example) to have security bugs like that old Bash security bug fixed is not that big of a risk either. To try to further justify that --tab feature, maybe a certain app would need root privileges to run, so noroot and nonewprivs would not be useful there, and one would therefore want to reduce the risk by not allowing the autocompletion in such a situation?

gitea-mirror commented

2026-05-05 09:34:50 -06:00

Author

Owner

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

I'm okay with enabling it since I have nonewprivs (and noroot) anyways*.

This does not protect you against CVE-2017-5932. See 4 Impact in https://raw.githubusercontent.com/jheyens/bash_completion_vuln/master/2017-01-17.bash_completion_report.pdf.

I feel that relying on Debian stable (for example) to have security bugs [..] fixed is not that big of a risk either.

In Debian stable you only get fixes for security bugs with a CVE

@rusty-snake commented on GitHub (Jun 16, 2022): > I'm okay with enabling it since I have nonewprivs (and noroot) anyways*. This does not protect you against CVE-2017-5932. See *4 Impact* in https://raw.githubusercontent.com/jheyens/bash_completion_vuln/master/2017-01-17.bash_completion_report.pdf. > I feel that relying on Debian stable (for example) to have security bugs [..] fixed is not that big of a risk either. In Debian stable you only get fixes for security bugs with a CVE

gitea-mirror commented

2026-05-05 09:34:51 -06:00

Author

Owner

@denizakcal commented on GitHub (Jun 17, 2022):

This does not protect you against CVE-2017-5932. See 4 Impact in https://raw.githubusercontent.com/jheyens/bash_completion_vuln/master/2017-01-17.bash_completion_report.pdf.

Sorry, but I'm not sure I understand.

The PDF you linked to says the following.:

Assuming an attacker has unprivileged account on a system, dropping a single file with the crafted name into a directory and asking an admin to investigate will elevate his privilege.

It seems to me like, assuming that that bug still existed and that I'm not using Firejail (because of not being able to be root within a Firejail sandbox with --noroot and --nonewprivs, which I'm using in this situation), if I never try to autocomplete with Bash in that directory as a root user, at worst, it would successfully download and run the malicious script, but it would not succeed at getting the non-root user's privileges elevated.

In order for the malicious actor to successfully elevate the non-root user's privileges, I, the only person with the root password, would need to (i) be in the directory with the maliciously-crafted file, (ii) be root (which would mean not using a Firejail sandbox having --noroot and --nonewprivs) and (iii) try to autocomplete (with Bash), right?

In Debian stable you only get fixes for security bugs with a CVE

Can't all serious security bugs "that can be fixed independently of any other problems" be filed as CVEs?

@denizakcal commented on GitHub (Jun 17, 2022): ### This does not protect you against [CVE-2017-5932](https://github.com/advisories/GHSA-7893-9j9h-935c). See _4 Impact_ in https://raw.githubusercontent.com/jheyens/bash_completion_vuln/master/2017-01-17.bash_completion_report.pdf. Sorry, but I'm not sure I understand. The PDF you linked to says the following.: > Assuming an attacker has unprivileged account on a system, dropping a single file with the crafted name into a directory and asking an admin to investigate will elevate his privilege. It seems to me like, assuming that that bug still existed and that I'm not using Firejail (because of not being able to be root within a Firejail sandbox with --noroot and --nonewprivs, which I'm using in this situation), if I never try to autocomplete with Bash in that directory as a root user, at worst, it would successfully download and run the malicious script, but it would not succeed at getting the non-root user's privileges elevated. In order for the malicious actor to successfully elevate the non-root user's privileges, I, the only person with the root password, would need to (i) be in the directory with the maliciously-crafted file, (ii) be root (which would mean not using a Firejail sandbox having --noroot and --nonewprivs) and (iii) try to autocomplete (with Bash), right? ### In Debian stable you only get fixes for security bugs with a CVE Can't all serious security bugs "that can be fixed independently of any other problems" be filed as CVEs?

gitea-mirror commented

2026-05-05 09:34:52 -06:00

Author

Owner

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

You can be root in a --noroot --nonewprivs configured sandbox.
Privileged escalation is more than user-to-root, it is less-privileged-to-more-privileged. So sandboxed-user-process-to-unsandboxed-user-process is privileged escalation too.
Firejail can not protect you because the vulnerable code runs outside of the firejail sandbox (unless you run every (interactive) bash in firejail. But even then it can not because such a sandbox would be very weak).

Can't all serious security bugs "that can be fixed independently of any other problems" be filed as CVEs?

Of course they can ... but it does not happen.
If a security vulnerability is discovered by a security researched it gets a CVE in 99.9% but if it gets discovered by upstream this is not always the case. Furthermore it can get fixed without being note during refactoring, hardening or fixing a non-security bug with actually is one. Or there is a upstream policy that bug with allow things you usually would count as a security vulnerabilities are not counted as security vulnerability if it can be done on a legal way too (e.g. keylogging in X11).

@rusty-snake commented on GitHub (Jun 17, 2022): 1. You can be root in a --noroot --nonewprivs configured sandbox. 2. Privileged escalation is more than user-to-root, it is less-privileged-to-more-privileged. So sandboxed-user-process-to-unsandboxed-user-process is privileged escalation too. 3. Firejail can not protect you because the vulnerable code runs outside of the firejail sandbox (unless you run *every* (interactive) bash in firejail. But even then it can not because such a sandbox would be very weak). > Can't all serious security bugs "that can be fixed independently of any other problems" be filed as CVEs? Of course they can ... but it does not happen. If a security vulnerability is discovered by a security researched it gets a CVE in 99.9% but if it gets discovered by upstream this is not always the case. Furthermore it can get fixed without being note during refactoring, hardening or fixing a non-security bug with actually is one. Or there is a upstream policy that bug with allow things you usually would count as a security vulnerabilities are not counted as security vulnerability if it can be done on a legal way too (e.g. keylogging in X11).

gitea-mirror commented

2026-05-05 09:34:53 -06:00

Author

Owner

@denizakcal commented on GitHub (Jun 18, 2022):

1.1. How so? For --nonewprivs, I guess it can be because one can find a way to acquire privileges without using execve (which is what the Firejail manual says --nonewprivs is supposed to prevent). But, for --noroot, the Firejail manual says that it is used to "install a user namespace with a single user - the current user" and that the "root user does not exist in the new namespace."

1.2. Oh, yes, I had forgotten about that. Thanks.

1.3. If the directory of the maliciously-crafted file (the fake home, in my case) is never accessed by anyone (whether a regular user or the root user) (directly or indirectly, such as from the PATH environment variable) from a non-Firejailed Bash process, then wouldn't all Bash processes (including the non-Firejailed ones) be safe from that bug? (My logic is that if a malicious actor tries to change something like the PATH environment variable from the Firejailed Bash processes (which would always be accessed via Firejail), it would only be the file(s) in the fake home directory that would be modified, which if I'm correct, shouldn't affect the real environment variables loaded in a regular Bash instance from the real home directory.)

Oh, thanks for the information.

@denizakcal commented on GitHub (Jun 18, 2022): 1.1. How so? For --nonewprivs, I guess it can be because one can find a way to acquire privileges without using execve (which is what the Firejail manual says --nonewprivs is supposed to prevent). But, for --noroot, the Firejail manual says that it is used to "install a user namespace with a single user - the current user" and that the "root user does not exist in the new namespace." 1.2. Oh, yes, I had forgotten about that. Thanks. 1.3. If the directory of the maliciously-crafted file (the fake home, in my case) is never accessed by anyone (whether a regular user or the root user) (directly or indirectly, such as from the PATH environment variable) from a non-Firejailed Bash process, then wouldn't all Bash processes (including the non-Firejailed ones) be safe from that bug? (My logic is that if a malicious actor tries to change something like the PATH environment variable from the Firejailed Bash processes (which would always be accessed via Firejail), it would only be the file(s) in the fake home directory that would be modified, which if I'm correct, shouldn't affect the real environment variables loaded in a regular Bash instance from the real home directory.) 2. Oh, thanks for the information.

gitea-mirror commented

2026-05-05 09:34:54 -06:00

Author

Owner

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

1.1. sudo firejail
1.3. The hole exploit is based on an more privileged bash process performs autocomplete in a directory with a malicious file.

@rusty-snake commented on GitHub (Jun 18, 2022): 1.1. `sudo firejail` 1.3. The hole exploit is based on an more privileged bash process performs autocomplete in a directory with a malicious file.

gitea-mirror commented

2026-05-05 09:34:54 -06:00

Author

Owner

@denizakcal commented on GitHub (Jun 18, 2022):

Oh, I see. Well, since I wouldn't be running the Firejailed Bash as root and that I wouldn't be accessing the fake home without Firejailing Bash, then it seems that my way of doing things is safe after all! :D

Thanks for the information!

@denizakcal commented on GitHub (Jun 18, 2022): Oh, I see. Well, since I wouldn't be running the Firejailed Bash as root and that I wouldn't be accessing the fake home without Firejailing Bash, then it seems that my way of doing things is safe after all! :D Thanks for the information!

Rows
Columns

[GH-ISSUE #5204] Autocomplete doesn't work in bash (when firejailed) #2916

This does not protect you against CVE-2017-5932. See 4 Impact in https://raw.githubusercontent.com/jheyens/bash_completion_vuln/master/2017-01-17.bash_completion_report.pdf.

In Debian stable you only get fixes for security bugs with a CVE