#1628 - [GH-ISSUE #2497] Firecfg multi-user behavior - error shown by default when only one user ran sudo firecfg - github-starred/firejail

gitea-mirror commented

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

Owner

Originally created by @Hocuri on GitHub (Mar 1, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2497

version: 0.9.58.2
Distro: Manjaro
Steps:
Run sudo firecfg with one user x
Switch to another user y
Run a git command, for example:
touch a b ; git diff --no-index a b

Result: Error: the user is not allowed to use Firejail. Please add the user in /etc/firejail/firejail.users file, either by running "sudo firecfg", or by editing the file directly. See "man firejail-users" for more details.

User y is not supposed to use Firejail (he doesn't need it) so I do not think that any error should be shown.

Originally created by @Hocuri on GitHub (Mar 1, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2497 - version: 0.9.58.2 - Distro: Manjaro - Steps: Run sudo firecfg with one user x Switch to another user y Run a git command, for example: `touch a b ; git diff --no-index a b` Result: `Error: the user is not allowed to use Firejail. Please add the user in /etc/firejail/firejail.users file, either by running "sudo firecfg", or by editing the file directly. See "man firejail-users" for more details.` User y is not supposed to use Firejail (he doesn't need it) so I do not think that any error should be shown.

gitea-mirror added the

information_old

firecfg

labels 2026-05-05 08:16:51 -06:00

gitea-mirror commented

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

Author

Owner

@Fred-Barclay commented on GitHub (Mar 2, 2019):

Hi @Hocuri
While I can see your point, I personally would disagree. In the interests of being transparent and also to avoid confusing lots of users who would otherwise have firejail refuse to run without warning, I think we should always advise when a user is not allowed to run firejail command. This would especially be problematic if the only reason the user couldn't run firejail was because of a typo or accidental misconfiguration on their part -- as it is now, it's hopefully easy for them to see what the error is and how to fix it. If we removed the warning, it'd be much harder for them to figure out what to do.

Sudo does something very similar too, for instance: username is not in the sudoers file. This incident will be reported. for chaps who don't have superuser permissions.

@Fred-Barclay commented on GitHub (Mar 2, 2019): Hi @Hocuri While I can see your point, I personally would disagree. In the interests of being transparent and **also** to avoid confusing lots of users who would otherwise have firejail refuse to run without warning, I think we should always advise when a user is not allowed to run `firejail` command. This would especially be problematic if the only reason the user couldn't run firejail was because of a typo or accidental misconfiguration on their part -- as it is now, it's hopefully easy for them to see what the error is and how to fix it. If we removed the warning, it'd be much harder for them to figure out what to do. Sudo does something very similar too, for instance: `username is not in the sudoers file. This incident will be reported.` for chaps who don't have superuser permissions.

gitea-mirror commented

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

Author

Owner

@Hocuri commented on GitHub (Mar 2, 2019):

Totally agree but I'm afraid that I expressed myself too vaguely - Imo Firejail shouldn't be launched at all if it wasn't configured for this account (i.e firejail shouldn't be executed). I guessed that it had something to do with me executing sudo firecfg from another account but I am not sure.

BTW do you have any idea what is trying to use Firejail? I mean, I just used git, why would I need Firejail?

@Hocuri commented on GitHub (Mar 2, 2019): Totally agree but I'm afraid that I expressed myself too vaguely - Imo Firejail shouldn't be launched at all if it wasn't configured for this account (i.e firejail shouldn't be executed). I guessed that it had something to do with me executing sudo firecfg from another account but I am not sure. BTW do you have any idea what is trying to use Firejail? I mean, I just used git, why would I need Firejail?

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Mar 2, 2019):

I guessed that it had something to do with me executing sudo firecfg from another account but I am not sure.

sudo firecfg is not per user, it ensures that some programs are executed by default in FJ, system-wide

BTW do you have any idea what is trying to use Firejail? I mean, I just used git, why would I need Firejail?

ls /usr/local/bin or ls -l /usr/local/bin --color=always | grep "firejail" --color=never all symlinks in /usr/local/bin pointing to firejail are executed by default in FJ.

@rusty-snake commented on GitHub (Mar 2, 2019): > I guessed that it had something to do with me executing sudo firecfg from another account but I am not sure. `sudo firecfg` is not per user, it ensures that some programs are executed by default in FJ, **system-wide** > BTW do you have any idea what is trying to use Firejail? I mean, I just used git, why would I need Firejail? `ls /usr/local/bin` or `ls -l /usr/local/bin --color=always | grep "firejail" --color=never` all symlinks in `/usr/local/bin` pointing to firejail are executed by default in FJ.

gitea-mirror commented

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

Author

Owner

@Hocuri commented on GitHub (Mar 4, 2019):

Thanks!
I found it out, it's less.

My suggestion for sudo firecfg:
Would you like to enable Firejail system-wide? (y/n)
If not, put the links to ~/.local/bin/ instead
If yes: Would you like to allow all desktop users to run Firejail? You can change this later. (y/n)
To change who can use Firejail run sudo nano /etc/configfilewhereever

(desktop user means uid >= 1000)

@Hocuri commented on GitHub (Mar 4, 2019): Thanks! I found it out, it's `less`. My suggestion for `sudo firecfg`: `Would you like to enable Firejail system-wide? (y/n)` If not, put the links to ~/.local/bin/ instead If yes: `Would you like to allow all desktop users to run Firejail? You can change this later. (y/n)` `To change who can use Firejail run sudo nano /etc/configfilewhereever` (desktop user means uid >= 1000)

gitea-mirror commented

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

Author

Owner

@smitsohu commented on GitHub (Mar 6, 2019):

If not, put the links to ~/.local/bin/ instead

It is an interesting idea, but this implies that there is a directory in user home with a high precedence in $PATH .... many distributions don't do this, and I think it is actually a best practice to not do this.

@smitsohu commented on GitHub (Mar 6, 2019): > If not, put the links to ~/.local/bin/ instead It is an interesting idea, but this implies that there is a directory in user home with a high precedence in $PATH .... many distributions don't do this, and I think it is actually a best practice to not do this.

gitea-mirror commented

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

Author

Owner

@Hocuri commented on GitHub (Mar 6, 2019):

The two distros I used up to now (Mint and Manjaro) do.

But I also think that Firecfg should check somehow whether ~/.local/bin/ really is in PATH. I do not know how do this if run by sudo though. So maybe we should just tell users to run Firecfg without sudo if they do not want to enable it for all users.

So:
sudo firecfg:
Firejail will be enabled system-wide. If you do not want this, press Ctrl+C now and run firecfg without sudo.
Would you like to allow all desktop users to run Firejail? You can change this later. (y/n)
To change who can use Firejail run sudo nano /etc/configfilewhereever

firecfgis able to inspect PATH then.

@Hocuri commented on GitHub (Mar 6, 2019): The two distros I used up to now (Mint and Manjaro) do. But I also think that Firecfg should check somehow whether ~/.local/bin/ really is in PATH. I do not know how do this if run by sudo though. So maybe we should just tell users to run Firecfg without sudo if they do not want to enable it for all users. So: `sudo firecfg`: `Firejail will be enabled system-wide. If you do not want this, press Ctrl+C now and run firecfg without sudo.` `Would you like to allow all desktop users to run Firejail? You can change this later. (y/n)` `To change who can use Firejail run sudo nano /etc/configfilewhereever` `firecfg`is able to inspect PATH then.

gitea-mirror commented

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

Author

Owner

@netblue30 commented on GitHub (Mar 11, 2019):

You can specify the directory where you want the symlinks using --bindir= command line option . Example (as regular user):

$ firecfg --bindir=~/.local/bin
$ firecfg --bindir=~/.local/bin --clean

@netblue30 commented on GitHub (Mar 11, 2019): You can specify the directory where you want the symlinks using --bindir= command line option . Example (as regular user): ````` $ firecfg --bindir=~/.local/bin $ firecfg --bindir=~/.local/bin --clean `````

gitea-mirror commented

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

Author

Owner

@Hocuri commented on GitHub (Mar 11, 2019):

Ah ok. I think that this should be the default behavior of firejail without sudo then, if .local/bin is in PATH.

Or, a more "complete" solution: https://github.com/netblue30/firejail/issues/2497#issuecomment-470209533

@Hocuri commented on GitHub (Mar 11, 2019): Ah ok. I think that this should be the default behavior of `firejail` without sudo then, if .local/bin is in PATH. Or, a more "complete" solution: https://github.com/netblue30/firejail/issues/2497#issuecomment-470209533

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Sep 10, 2019):

@netblue current this is labled with "information", is @Hocuri's idea a won't fix or should be add "enhancement"?

@rusty-snake commented on GitHub (Sep 10, 2019): @netblue current this is labled with "information", is @Hocuri's idea a won't fix or should be add "enhancement"?

Rows
Columns

[GH-ISSUE #2497] Firecfg multi-user behavior - error shown by default when only one user ran sudo firecfg #1628