Paths blacklisted using ${PATH} can't be unblacklisted using expanded paths (which works for other variables)

[smheidrich]

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)