whitelist and noblacklist seems to have no effect

[odiferousmint]

firejail version 0.9.58.2

Compile time support:
        - AppArmor support is disabled
        - AppImage support is enabled
        - chroot support is enabled
        - file and directory whitelisting support is enabled
        - file transfer support is enabled
        - networking support is enabled
        - overlayfs support is enabled
        - private-home support is enabled
        - seccomp-bpf support is enabled
        - user namespace support is enabled
        - X11 sandboxing support is enabled

Config:

include /etc/firejail/globals.local

caps.drop all
netfilter
nodvd
nogroups
nonewprivs
#noroot
notv
protocol unix,inet,inet6,netlink
seccomp
shell none

private-cache
private-dev
private-tmp

noexec /tmp

Then I tried:

whitelist /home/odiferousmint/foo

and

noblacklist /home/odiferousmint/foo

both together, and separately.

The program I used is VSCodium. I tried to open a file that exists inside /home/odiferousmint/foo, but there are no directories in /home/odiferousmint.

Why?

I would also like to note that my configurations were not persistent/permanent either, even though I tried whitelisting and noblacklisting the directory in which the configuration files are placed. Workaround for using the right configurations upon startup is start the program without firejail, configure the program, then start again with firejail. Seems messy. I had no such issues in earlier versions of firejail.

[Vincent43]

Is /home/odiferousmint/ invoking user $HOME? whitelist in dirs under /home other than $HOME in not supported.

[odiferousmint]

What exactly do you mean?

$ echo $HOME
/home/odiferousmint

Can I not make programs see files and directories under my home directory? :/

I think it is a bug because the same whitelist / noblacklist is present in many profile files. Look at /etc/firejail/code.profile. It has noblacklist ${HOME}/.config/Code. I have the same but for some reason the changes are not saved. This is actually odd because the executable itself is located under $HOME/.local/pkg/VSCodium-1.13.1, and without whitelisting that, it cannot find it, so I have it whitelisted which makes the executable run. So ultimately it sometimes works, sometimes it doesn't? I have no idea.

Edit: I changed many things, I am not sure why but whitelist works now. I did some reordering too, maybe that's what fixed it. I know it matters for the executable. If you guys cannot reproduce the issue then it was probably my fault and sorry in advance. Feel free to close it if it's non-reproducible.

---

I don't want to create another issue for this but this is odd. Look at /etc/firejail/wire-desktop.profile as well.

noblacklist ${HOME}/.config/Wire
mkdir ${HOME}/.config/Wire
whitelist ${HOME}/.config/Wire

Is this intentional, if so, what is the reasoning behind this?

[Fred-Barclay]

I don't want to create another issue for this but this is odd. Look at /etc/firejail/wire-desktop.profile as well.

noblacklist ${HOME}/.config/Wire
mkdir ${HOME}/.config/Wire
whitelist ${HOME}/.config/Wire

Is this intentional, if so, what is the reasoning behind this?

It's partly a redundant security fail-safe so that if someone decides to un-whitelist the wire profile, sensitive files still won't be visible inside the sandbox.

It's really important that ~/.config/Wire isn't visible to most programs running in firejail, so we blacklist it in /etc/firejail/disable-programs.inc. noblacklist undoes this to make it accessible to Wire (as it ought to be). AFAIK it isn't strictly necessary unless someone removes whitelisting from the profile -- then it's vital if you want Wire to work.

mkdir makes sure the directory exists. Without this line, Wire will work correctly, but any changes you make (like settings) won't be saved once you close the sandbox. This is only necessary since we have a whitelist call (if a profile only contains blacklists, we don't have to use mkdir).

whitelist, of course, blocks access to (most) other files besides ~/.config/Wire.

See #1569 for a historical note on the subject if you're interested. 😄

Cheers!
Fred

[matu3ba]

Suggestion to close this.

[rusty-snake]

@odiferousmint
I'm closing here due to inactivity, please fell free to reopen if you have more questions.