github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #2419] `whitelist` and `noblacklist` seems to have no effect #1612

New issue

Closed

opened 2026-05-05 08:16:14 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

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

Owner

Originally created by @odiferousmint on GitHub (Feb 18, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2419

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.

Originally created by @odiferousmint on GitHub (Feb 18, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2419 ``` 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`.

gitea-mirror

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

closed this issue
added the
question_old
label

gitea-mirror commented

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

Author

Owner

@Vincent43 commented on GitHub (Feb 18, 2019):

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

@Vincent43 commented on GitHub (Feb 18, 2019): Is `/home/odiferousmint/` invoking user `$HOME`? whitelist in dirs under `/home` other than `$HOME` in not supported.

gitea-mirror commented

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

Author

Owner

@odiferousmint commented on GitHub (Feb 19, 2019):

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?

@odiferousmint commented on GitHub (Feb 19, 2019): 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?

gitea-mirror commented

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

Author

Owner

@Fred-Barclay commented on GitHub (Feb 19, 2019):

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

@Fred-Barclay commented on GitHub (Feb 19, 2019): > 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. :smile: Cheers! Fred

gitea-mirror commented

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

Author

Owner

@matu3ba commented on GitHub (Jul 9, 2019):

Suggestion to close this.

@matu3ba commented on GitHub (Jul 9, 2019): Suggestion to close this.

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Jul 9, 2019):

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

@rusty-snake commented on GitHub (Jul 9, 2019): @odiferousmint I'm closing here due to inactivity, please fell free to reopen if you have more questions.

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

No description provided.

Rows
Columns

[GH-ISSUE #2419] whitelist and noblacklist seems to have no effect #1612

[GH-ISSUE #2419] `whitelist` and `noblacklist` seems to have no effect #1612