[GH-ISSUE #6360] Paths blacklisted using ${PATH} can't be unblacklisted using expanded paths (which works for other variables) #3248

New issue

Open

opened 2026-05-05 09:51:20 -06:00 by gitea-mirror · 0 comments

gitea-mirror commented

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

Owner

Originally created by @smheidrich on GitHub (May 26, 2024).
Original GitHub issue: https://github.com/netblue30/firejail/issues/6360

Description

Paths that are blacklisted using the ${PATH} expansion can't be un-blacklisted using --noblacklist on the expanded path, which works fine for other variable expansions.

Steps to Reproduce

Set up an executable e.g. in /bin (as root): echo $'#!/bin/bash\necho ok' > /bin/some-executable && chmod +x /bin/some-executable
Sanity check: Try blacklisting it via ${PATH}, then unblacklisting it via its unexpanded path, which works fine (but the order of CLI options has to be reversed for whatever reason - another option would be to do the blacklisting in a profile file): firejail --noblacklist='${PATH}/some-executable' --blacklist='${PATH}/some-executable', then run some-executable inside the sandboxed shell; it runs fine.
Now try the same but with the expanded path used for unblacklisting, which doesn't work: firejail --noblacklist='/bin/some-executable' --blacklist='${PATH}/some-executable', then run some-executable inside the sandboxed shell

Expected behavior

It should run fine as well.

Actual behavior

It reports a "permission denied" error because it's still blacklisted.

Behavior without a profile

The profile is irrelevant here because it's about rules for files we've just made up ourselves.

Additional context

The same thing works fine for other variables like ${HOME}, as well as for other expansions like wildcards.

E.g. I can create a file some-file in my home directory, and it doesn't matter whether I do firejail --noblacklist='${HOME}/some-file' --blacklist='${HOME}/some-file' or firejail --noblacklist='/home/smheidrich/some-file' --blacklist='${HOME}/some-file', in either case the file is accessible because it got unblacklisted successfully.

It's seems like it's only ${PATH} that behaves inconsistently with the other expansions.

This was first noticed while drafting #6359, which aims to improve the manpage. If this inconsistency isn't considered a bug, then it should definitely be mentioned in the manpage. It also breaks the current --noblacklist example, which tries to unblacklist nc using its expanded path.

Environment

Debian Linux 12
firejail version 0.9.72

Checklist

The issues is caused by firejail (i.e. running the program by path (e.g. /usr/bin/vlc) "fixes" it).
I can reproduce the issue without custom modifications (e.g. globals.local).
N/A [ ] The program has a profile. (If not, request one in https://github.com/netblue30/firejail/issues/1139)
N/A [ ] The profile (and redirect profile if exists) hasn't already been fixed upstream.
I have performed a short search for similar issues (to avoid opening a duplicate).
N/A - [ ] I'm aware of browser-allow-drm yes/browser-disable-u2f no in firejail.config to allow DRM/U2F in browsers.
N/A [ ] I used --profile=PROFILENAME to set the right profile. (Only relevant for AppImages)

Originally created by @smheidrich on GitHub (May 26, 2024). Original GitHub issue: https://github.com/netblue30/firejail/issues/6360 ### Description Paths that are blacklisted using the `${PATH}` expansion can't be un-blacklisted using `--noblacklist` on the expanded path, which works fine for other variable expansions. ### Steps to Reproduce - Set up an executable e.g. in `/bin` (as root): `echo $'#!/bin/bash\necho ok' > /bin/some-executable && chmod +x /bin/some-executable` - Sanity check: Try blacklisting it via `${PATH}`, then unblacklisting it via its unexpanded path, which works fine (but the order of CLI options has to be reversed for whatever reason - another option would be to do the blacklisting in a profile file): `firejail --noblacklist='${PATH}/some-executable' --blacklist='${PATH}/some-executable'`, then run `some-executable` inside the sandboxed shell; it runs fine. - Now try the same but with the expanded path used for unblacklisting, which doesn't work: `firejail --noblacklist='/bin/some-executable' --blacklist='${PATH}/some-executable'`, then run `some-executable` inside the sandboxed shell ### Expected behavior It should run fine as well. ### Actual behavior It reports a "permission denied" error because it's still blacklisted. ### Behavior without a profile The profile is irrelevant here because it's about rules for files we've just made up ourselves. ### Additional context The same thing works fine for other variables like `${HOME}`, as well as for other expansions like wildcards. E.g. I can create a file `some-file` in my home directory, and it doesn't matter whether I do `firejail --noblacklist='${HOME}/some-file' --blacklist='${HOME}/some-file'` or `firejail --noblacklist='/home/smheidrich/some-file' --blacklist='${HOME}/some-file'`, in either case the file is accessible because it got unblacklisted successfully. It's seems like it's only `${PATH}` that behaves inconsistently with the other expansions. This was first noticed while drafting #6359, which aims to improve the manpage. If this inconsistency isn't considered a bug, then it should definitely be mentioned in the manpage. It also breaks the current `--noblacklist` example, which tries to unblacklist `nc` using its expanded path. ### Environment - Debian Linux 12 - firejail version 0.9.72 ### Checklist - [x] The issues is caused by firejail (i.e. running the program by path (e.g. `/usr/bin/vlc`) "fixes" it). - [x] I can reproduce the issue without custom modifications (e.g. globals.local). - N/A [ ] The program has a profile. (If not, request one in `https://github.com/netblue30/firejail/issues/1139`) - N/A [ ] The profile (and redirect profile if exists) hasn't already been fixed [upstream](https://github.com/netblue30/firejail/tree/master/etc). - [x] I have performed a short search for similar issues (to avoid opening a duplicate). N/A - [ ] I'm aware of `browser-allow-drm yes`/`browser-disable-u2f no` in `firejail.config` to allow DRM/U2F in browsers. - N/A [ ] I used `--profile=PROFILENAME` to set the right profile. (Only relevant for AppImages)

gitea-mirror added the

enhancement

label 2026-05-05 09:51:20 -06:00

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

No description provided.

Rows
Columns