[GH-ISSUE #1450] firecfg incompletely installing

gitea-mirror commented

2026-05-05 07:14:59 -06:00

Owner

Originally created by @Boruch-Baum on GitHub (Aug 9, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1450

For firejail version 0.9.48, in debian, firecfg is not creating symlinks for all available profiles.

This proved to be very frustrating when trying to figure out why a process tree consisting of less / .lessfilter / highlight was being rejected by firejail. Once I manually created the symlink, the operation succeeded.

Just in case there might be a second issue here, the case was:

$ less /usr/share/doc/abook/README
Blacklist violations are logged to syslog
0;firejail /usr/bin/highlight --out-format=xterm256 /usr/share/doc/abook/README ^GParent pid 13631, child pid 13632
Parent is shutting down, bye...

Before I wised up and noticed the lack of the symlink, the following WOULD succeed:

firejail --noprofile less /usr/share/doc/abook/README

Originally created by @Boruch-Baum on GitHub (Aug 9, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1450 For firejail version 0.9.48, in debian, firecfg is not creating symlinks for all available profiles. This proved to be very frustrating when trying to figure out why a process tree consisting of less / .lessfilter / highlight was being rejected by firejail. Once I manually created the symlink, the operation succeeded. Just in case there might be a second issue here, the case was: $ less /usr/share/doc/abook/README Blacklist violations are logged to syslog 0;firejail /usr/bin/highlight --out-format=xterm256 /usr/share/doc/abook/README ^GParent pid 13631, child pid 13632 Parent is shutting down, bye... Before I wised up and noticed the lack of the symlink, the following WOULD succeed: firejail --noprofile less /usr/share/doc/abook/README

gitea-mirror

2026-05-05 07:14:59 -06:00

closed this issue
added the
enhancement

bug
labels

gitea-mirror commented

2026-05-05 07:15:04 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 10, 2017):

You can try the version on git mainline. less command was added after 0.9.48 release.

@netblue30 commented on GitHub (Aug 10, 2017): You can try the version on git mainline. less command was added after 0.9.48 release.

gitea-mirror commented

2026-05-05 07:15:05 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Aug 10, 2017):

Debian occasionally adds/removes stuff so maybe they put the less.profile in version 0.9.48, because it is there. What didn't happen was when I ran firecfg, it didn't create the symlink for very many commands that had profiles in the /etc/firejail directory, the first of which I noticed now when debugging my problem with less. Most of the missing symlinks are for programs not currenlty installed on my system.

Is firecfg supposed to create links for all profiles in the /etc/firejail directory?

If you mean that the file 'less.profile' really shouldn't be in my version (ie. debian patched it in), then should I manually write a simple one-liner script to create symlinks for everything in the directory?

@Boruch-Baum commented on GitHub (Aug 10, 2017): Debian occasionally adds/removes stuff so maybe they put the less.profile in version 0.9.48, because it is there. What didn't happen was when I ran firecfg, it didn't create the symlink for very many commands that had profiles in the /etc/firejail directory, the first of which I noticed now when debugging my problem with less. Most of the missing symlinks are for programs not currenlty installed on my system. Is firecfg supposed to create links for all profiles in the /etc/firejail directory? If you mean that the file 'less.profile' really shouldn't be in my version (ie. debian patched it in), then should I manually write a simple one-liner script to create symlinks for everything in the directory?

gitea-mirror commented

2026-05-05 07:15:06 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Aug 10, 2017):

Is firecfg supposed to create links for all profiles in the /etc/firejail directory?

I think the intention is for all profiles in /etc/firejail/ to be linked, but in reality we've had to leave a few out for various reasons. You can see which programs should always be linked in src/firecfg/firecfg.config.

@Fred-Barclay commented on GitHub (Aug 10, 2017): > Is firecfg supposed to create links for all profiles in the /etc/firejail directory? I think the *intention* is for all profiles in /etc/firejail/ to be linked, but in reality we've had to leave a few out for various reasons. You can see which programs should always be linked in src/firecfg/firecfg.config.

gitea-mirror commented

2026-05-05 07:15:07 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Aug 10, 2017):

Thanks @Fred-Barclay. My install only created 62 of 309 symlinks.

I must admit that the whole resort to symlinks makes me a bit uneasy, as it will break for any scenario using absolute paths (eg. legacy scripts), and it makes firejail easy to intentionally circumvent. I expect you've hashed out the pros and cons already.

Have you considered this option?: It's pretty clear that this project is going to single-handedly 'take over' the /usr/local/bin directory, which concerns me, from a 'big picture' perspective. Have you considered putting the symlinks in a dedicated directory (eg. /usr/bin/firejail, /usr/lib/firejail), and asking users (or distributions, or sysadmins) that as part of the install process they should add that dedicated directory to their $PATH ? That would keep /usr/local/bin for its original purpose and allow for firejail to operate upon real executables that a local sysadmin correctly wants to exist in that directory. I realise this suggestion is late in the game, so possibly introduce it as an option, or just mention in the documentation the notion of doing so manually (if there wouldn't be aproblem with that working).

@Boruch-Baum commented on GitHub (Aug 10, 2017): Thanks @Fred-Barclay. My install only created 62 of 309 symlinks. I must admit that the whole resort to symlinks makes me a bit uneasy, as it will break for any scenario using absolute paths (eg. legacy scripts), and it makes firejail easy to intentionally circumvent. I expect you've hashed out the pros and cons already. Have you considered this option?: It's pretty clear that this project is going to single-handedly 'take over' the /usr/local/bin directory, which concerns me, from a 'big picture' perspective. Have you considered putting the symlinks in a dedicated directory (eg. /usr/bin/firejail, /usr/lib/firejail), and asking users (or distributions, or sysadmins) that as part of the install process they should add that dedicated directory to their $PATH ? That would keep /usr/local/bin for its original purpose and allow for firejail to operate upon real executables that a local sysadmin correctly wants to exist in that directory. I realise this suggestion is late in the game, so possibly introduce it as an option, or just mention in the documentation the notion of doing so manually (if there wouldn't be aproblem with that working).

gitea-mirror commented

2026-05-05 07:15:09 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Aug 10, 2017):

My install only created 62 of 309 symlinks.

It'll only create symlinks for profiles that it has located in /etc/firejail and that are installed

it makes firejail easy to intentionally circumvent

Its not really meant to prevent a malicious user sitting at the computer, and more of reducing harm by exploits/malware.

putting the symlinks in a dedicated directory

That could probably be easily added as an option in firejail.config, eg. "firecfg-use-dedicated-dir", and then just have firecfg add a warning if it doesn't detect it in $PATH

@SkewedZeppelin commented on GitHub (Aug 10, 2017): > My install only created 62 of 309 symlinks. It'll only create symlinks for profiles that it has located in /etc/firejail and that are installed > it makes firejail easy to intentionally circumvent Its not really meant to prevent a malicious user sitting at the computer, and more of reducing harm by exploits/malware. > putting the symlinks in a dedicated directory That could probably be easily added as an option in firejail.config, eg. "firecfg-use-dedicated-dir", and then just have firecfg add a warning if it doesn't detect it in $PATH

gitea-mirror commented

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

Author

Owner

@Boruch-Baum commented on GitHub (Aug 10, 2017):

In practice, at this point, I'm tremendously gratified that firejail is easy to circumvent, as I've been going through more install pain. Here's a continuation:

As I mentioned in my opening comment, I have 'less' call a shell script called ~/.lessfilter, which decides how to colorize less output. For many files, it uses GNU highlight, and for log files, it uses ccze. When I open a root terminal to examine my syslog, I'm now getting the message:

# less /var/log/syslog
/root/.lessfilter: 32: /root/.lessfilter: cannot open /var/log/syslog: No such file

# firejail --whitelist=/var/log --whitelist=/var/log/syslog  --profile=/etc/firejail/less.profile less syslog
Warning: an existing sandbox was detected. /usr/bin/less will run without any additional sandboxing features
/root/.lessfilter: 32: /root/.lessfilter: cannot open /var/log/syslog: No such file

What seems to be happening is that the whitelists work for commands early in the script .lessfilter (eg. readlink, dirname), but not for a call to ccze (my line 32), in the form "ccze -A <"$1" , where $1 would be /var/log/syslog.

Note that if I try:

# firejail --profile=/etc/firejail/less.profile less syslog

without both whitelists, the script fails earlier, when trying to run dirname

What is going on? Do I need a separate profile for ccze? If so, why not for readlink and dirname? Why when explicitly calling less.profile does it behave differently than when called by default? Does the redirection in the script mess things up?

For colorizing log files, this is a tremendous waste of time, but for figuring out what's going on in firejail not so much.

@Boruch-Baum commented on GitHub (Aug 10, 2017): In practice, at this point, I'm tremendously gratified that firejail is easy to circumvent, as I've been going through more install pain. Here's a continuation: As I mentioned in my opening comment, I have 'less' call a shell script called ~/.lessfilter, which decides how to colorize less output. For many files, it uses GNU highlight, and for log files, it uses ccze. When I open a root terminal to examine my syslog, I'm now getting the message: # less /var/log/syslog /root/.lessfilter: 32: /root/.lessfilter: cannot open /var/log/syslog: No such file # firejail --whitelist=/var/log --whitelist=/var/log/syslog --profile=/etc/firejail/less.profile less syslog Warning: an existing sandbox was detected. /usr/bin/less will run without any additional sandboxing features /root/.lessfilter: 32: /root/.lessfilter: cannot open /var/log/syslog: No such file What seems to be happening is that the whitelists work for commands early in the script .lessfilter (eg. readlink, dirname), but not for a call to ccze (my line 32), in the form "ccze -A <"$1" , where $1 would be /var/log/syslog. Note that if I try: # firejail --profile=/etc/firejail/less.profile less syslog without both whitelists, the script fails earlier, when trying to run dirname What is going on? Do I need a separate profile for ccze? If so, why not for readlink and dirname? Why when explicitly calling less.profile does it behave differently than when called by default? Does the redirection in the script mess things up? For colorizing log files, this is a tremendous waste of time, but for figuring out what's going on in firejail not so much.

gitea-mirror commented

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

Author

Owner

@reinerh commented on GitHub (Aug 10, 2017):

That's not an issue with your script.
By default firejail only mounts a minimal /var/log into the sandbox.
See:

$ firejail --quiet --noprofile ls -l /var/log | grep syslog
$ firejail --quiet --noprofile --writable-var-log ls -l /var/log | grep syslog
-rw-r----- 1 root          adm              2873 Aug 10 10:17 syslog
-rw-r----- 1 root          adm            189753 Aug 10 10:02 syslog.1
-rw-r----- 1 root          adm             27305 Aug  9 11:08 syslog.2.gz
-rw-r----- 1 root          adm             24887 Aug  8 11:28 syslog.3.gz
-rw-r----- 1 root          adm             25024 Aug  7 12:18 syslog.4.gz
-rw-r----- 1 root          adm             15226 Aug  6 11:24 syslog.5.gz
-rw-r----- 1 root          adm             22555 Aug  5 12:39 syslog.6.gz
-rw-r----- 1 root          adm             29515 Aug  4 12:17 syslog.7.gz

If you need this, you can add writable-var-log to your local less profile.

@reinerh commented on GitHub (Aug 10, 2017): That's not an issue with your script. By default firejail only mounts a minimal /var/log into the sandbox. See: ``` $ firejail --quiet --noprofile ls -l /var/log | grep syslog $ firejail --quiet --noprofile --writable-var-log ls -l /var/log | grep syslog -rw-r----- 1 root adm 2873 Aug 10 10:17 syslog -rw-r----- 1 root adm 189753 Aug 10 10:02 syslog.1 -rw-r----- 1 root adm 27305 Aug 9 11:08 syslog.2.gz -rw-r----- 1 root adm 24887 Aug 8 11:28 syslog.3.gz -rw-r----- 1 root adm 25024 Aug 7 12:18 syslog.4.gz -rw-r----- 1 root adm 15226 Aug 6 11:24 syslog.5.gz -rw-r----- 1 root adm 22555 Aug 5 12:39 syslog.6.gz -rw-r----- 1 root adm 29515 Aug 4 12:17 syslog.7.gz ``` If you need this, you can add `writable-var-log` to your local less profile.

gitea-mirror commented

2026-05-05 07:15:11 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Aug 10, 2017):

Thanks, @reinerh! What a relief!

However, this raises another question? This is the kind of setting that should be default for any user with admin privileges probably for many command profiles, so how are such people (sysadmins, root account) expected to use firejail? Must they / we manually copy and customize all profiles to /root/.config/firejail ?

@Boruch-Baum commented on GitHub (Aug 10, 2017): Thanks, @reinerh! What a relief! However, this raises another question? This is the kind of setting that should be default for any user with admin privileges probably for many command profiles, so how are such people (sysadmins, root account) expected to use firejail? Must they / we manually copy and customize all profiles to /root/.config/firejail ?

gitea-mirror commented

2026-05-05 07:15:12 -06:00

Author

Owner

@reinerh commented on GitHub (Aug 10, 2017):

If you intend to use less on for example /var/log/syslog and don't do it that often, you could use the command line flag.
If you use it more often you could put it into /etc/firejail/less.local (which is loaded in the /etc/firejail/less.profile profile).
If you use it even more with also other tools, you can put it into /etc/firejail/globals.local, which is loaded by all profiles.

@reinerh commented on GitHub (Aug 10, 2017): If you intend to use less on for example /var/log/syslog and don't do it that often, you could use the command line flag. If you use it more often you could put it into /etc/firejail/less.local (which is loaded in the /etc/firejail/less.profile profile). If you use it even more with also other tools, you can put it into /etc/firejail/globals.local, which is loaded by all profiles.

gitea-mirror commented

2026-05-05 07:15:13 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Aug 10, 2017):

@reinerh, your solution worked like a charm.

So in a multi-user environment that would mean, for example,
creating a file /root/.config/firejail/globals.local?

I imagine as firejail becomes more popular, this type of dual-use issue will arise often and consistently, because even a single-user device that maintains a distinction between a normal and a privileged state (eg sudo), will need some special ruleset for the privileged account(s).

@Boruch-Baum commented on GitHub (Aug 10, 2017): @reinerh, your solution worked like a charm. So in a multi-user environment that would mean, for example, creating a file /root/.config/firejail/globals.local? I imagine as firejail becomes more popular, this type of dual-use issue will arise often and consistently, because even a single-user device that maintains a distinction between a normal and a privileged state (eg sudo), will need some special ruleset for the privileged account(s).

gitea-mirror commented

2026-05-05 07:15:14 -06:00

Author

Owner

@reinerh commented on GitHub (Aug 10, 2017):

$HOME/.config/firejail/globals.local would not work, because this file is nowhere included.
What you could do (but would be a bit more effort) is creating user-local profiles that load the normal profile and a user-local global overwrite, like this (/root/.config/firejail/less.profile):

include /root/.config/firejail/globals.local
include /etc/firejail/less.profile

Then you can put your user-specific global overwrites to this globals.local file.

@reinerh commented on GitHub (Aug 10, 2017): $HOME/.config/firejail/globals.local would not work, because this file is nowhere included. What you could do (but would be a bit more effort) is creating user-local profiles that load the normal profile and a user-local global overwrite, like this (/root/.config/firejail/less.profile): ``` include /root/.config/firejail/globals.local include /etc/firejail/less.profile ``` Then you can put your user-specific global overwrites to this globals.local file.

gitea-mirror commented

2026-05-05 07:15:15 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Aug 10, 2017):

Thanks. At this point, for me personally, the issue could be closed as solved, but it would be considerate for other users maybe to keep it open for a conversation / decision about whether / what something should be done in the package to address this for others. The people deciding to install / deploy firejail are going to be sysadmins themselves (at least in some sense of the word), and the current situation will give them a frustrating first impression that may cause them to just ditch the idea of using firejail if its a hassle for them.

@Boruch-Baum commented on GitHub (Aug 10, 2017): Thanks. At this point, for me personally, the issue could be closed as solved, but it would be considerate for other users maybe to keep it open for a conversation / decision about whether / what something should be done in the package to address this for others. The people deciding to install / deploy firejail are going to be sysadmins themselves (at least in some sense of the word), and the current situation will give them a frustrating first impression that may cause them to just ditch the idea of using firejail if its a hassle for them.

gitea-mirror commented

2026-05-05 07:15:16 -06:00

Author

Owner

@netblue30 commented on GitHub (Aug 10, 2017):

I put a fix in git. It turns out we already have a --writable-var-log command line option and profile command to disable the sandboxing of /var/log. Also, let's not add private-bin to the profile, ~/.lessfilter seems to be quite popular with power users.

In the next version we'll add another way to handle desktop integration based on a LD_PRELOAD library, so you wouldn't have to mess with /usr/local/bin.

@netblue30 commented on GitHub (Aug 10, 2017): I put a fix in git. It turns out we already have a --writable-var-log command line option and profile command to disable the sandboxing of /var/log. Also, let's not add private-bin to the profile, ~/.lessfilter seems to be quite popular with power users. In the next version we'll add another way to handle desktop integration based on a LD_PRELOAD library, so you wouldn't have to mess with /usr/local/bin.

gitea-mirror commented

2026-05-05 07:15:16 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 25, 2020):

Is there anything left to do here?

@rusty-snake commented on GitHub (Jan 25, 2020): Is there anything left to do here?

Rows
Columns

[GH-ISSUE #1450] firecfg incompletely installing #976