[GH-ISSUE #1569] Why do we have blacklist, noblacklist, and whitelist in the same profile?

gitea-mirror commented

2026-05-05 07:21:01 -06:00

Owner

Originally created by @Fred-Barclay on GitHub (Sep 21, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1569

Is there a particular reason or historical significance for including disable-programs.inc, then noblacklisting the files we need, and then whitelisting those files?
Take the firefox profile for instance. We blacklist quite a few files in ${HOME} with include /etc/firejail/disable-programs.inc, and then noblacklist the ones we need:

noblacklist ~/.config/okularpartrc
noblacklist ~/.config/okularrc
noblacklist ~/.config/qpdfview
noblacklist ~/.kde/share/apps/okular
noblacklist ~/.kde/share/config/okularpartrc
noblacklist ~/.kde/share/config/okularrc
noblacklist ~/.kde4/share/apps/okular
noblacklist ~/.kde4/share/config/okularpartrc
noblacklist ~/.kde4/share/config/okularrc
noblacklist ~/.local/share/gnome-shell/extensions
noblacklist ~/.local/share/okular
noblacklist ~/.local/share/qpdfview
noblacklist ~/.mozilla
noblacklist ~/.pki

We then whitelist these files:

mkdir ~/.mozilla
mkdir ~/.pki
whitelist ${DOWNLOADS}
whitelist ~/.cache/gnome-mplayer/plugin
whitelist ~/.cache/mozilla/firefox
whitelist ~/.config/gnome-mplayer
whitelist ~/.config/okularpartrc
whitelist ~/.config/okularrc
whitelist ~/.config/pipelight-silverlight5.1
whitelist ~/.config/pipelight-widevine
whitelist ~/.config/qpdfview
whitelist ~/.kde/share/apps/okular
whitelist ~/.kde/share/config/okularpartrc
whitelist ~/.kde/share/config/okularrc
whitelist ~/.kde4/share/apps/okular
whitelist ~/.kde4/share/config/okularpartrc
whitelist ~/.kde4/share/config/okularrc
whitelist ~/.keysnail.js
whitelist ~/.lastpass
whitelist ~/.local/share/gnome-shell/extensions
whitelist ~/.local/share/okular
whitelist ~/.local/share/qpdfview
whitelist ~/.mozilla
whitelist ~/.pentadactyl
whitelist ~/.pentadactylrc
whitelist ~/.pki
whitelist ~/.vimperator
whitelist ~/.vimperatorrc
whitelist ~/.wine-pipelight
whitelist ~/.wine-pipelight64
whitelist ~/.zotero
whitelist ~/dwhelper
include /etc/firejail/whitelist-common.inc
include /etc/firejail/whitelist-var-common.inc

Instead of having to blacklist so many files, then noblacklist the ones we need, and then whitelist the those files, why not just keep the whitelist filter and do away with including disable-programs.inc and the noblacklist filter? Since whitelist effectively blacklists all files except the ones it's given, this would have the same effect as what we're already doing but greatly reduce the complexity of many profiles.

Thoughts? Am I missing something?
(Credits to this poster for pointing this out.)

Originally created by @Fred-Barclay on GitHub (Sep 21, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1569 Is there a particular reason or historical significance for including disable-programs.inc, then noblacklisting the files we need, and then whitelisting those files? Take the firefox profile for instance. We blacklist quite a few files in ${HOME} with `include /etc/firejail/disable-programs.inc`, and then noblacklist the ones we need: ```noblacklist ~/.cache/mozilla noblacklist ~/.config/okularpartrc noblacklist ~/.config/okularrc noblacklist ~/.config/qpdfview noblacklist ~/.kde/share/apps/okular noblacklist ~/.kde/share/config/okularpartrc noblacklist ~/.kde/share/config/okularrc noblacklist ~/.kde4/share/apps/okular noblacklist ~/.kde4/share/config/okularpartrc noblacklist ~/.kde4/share/config/okularrc noblacklist ~/.local/share/gnome-shell/extensions noblacklist ~/.local/share/okular noblacklist ~/.local/share/qpdfview noblacklist ~/.mozilla noblacklist ~/.pki ``` We then whitelist these files: ```mkdir ~/.cache/mozilla/firefox mkdir ~/.mozilla mkdir ~/.pki whitelist ${DOWNLOADS} whitelist ~/.cache/gnome-mplayer/plugin whitelist ~/.cache/mozilla/firefox whitelist ~/.config/gnome-mplayer whitelist ~/.config/okularpartrc whitelist ~/.config/okularrc whitelist ~/.config/pipelight-silverlight5.1 whitelist ~/.config/pipelight-widevine whitelist ~/.config/qpdfview whitelist ~/.kde/share/apps/okular whitelist ~/.kde/share/config/okularpartrc whitelist ~/.kde/share/config/okularrc whitelist ~/.kde4/share/apps/okular whitelist ~/.kde4/share/config/okularpartrc whitelist ~/.kde4/share/config/okularrc whitelist ~/.keysnail.js whitelist ~/.lastpass whitelist ~/.local/share/gnome-shell/extensions whitelist ~/.local/share/okular whitelist ~/.local/share/qpdfview whitelist ~/.mozilla whitelist ~/.pentadactyl whitelist ~/.pentadactylrc whitelist ~/.pki whitelist ~/.vimperator whitelist ~/.vimperatorrc whitelist ~/.wine-pipelight whitelist ~/.wine-pipelight64 whitelist ~/.zotero whitelist ~/dwhelper include /etc/firejail/whitelist-common.inc include /etc/firejail/whitelist-var-common.inc ``` Instead of having to blacklist so many files, then noblacklist the ones we need, and then whitelist the those files, why not just keep the whitelist filter and do away with including disable-programs.inc and the noblacklist filter? Since whitelist effectively blacklists all files except the ones it's given, this would have the same effect as what we're already doing but greatly reduce the complexity of many profiles. Thoughts? Am I missing something? (Credits to [this poster](https://forums.linuxmint.com/viewtopic.php?f=58&t=254065&p=1368702#p1368684) for pointing this out.)

gitea-mirror

2026-05-05 07:21:01 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 07:21:05 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 21, 2017):

If a user wants to let a program access files in another directory and they decide to disable the whitelist in a local copy, the profile will still be restricted from reading the contents of other programs (which is good!). If blacklist wasn't included and they disabled whitelist, it'd have (near) full access to their home directory (which is very bad!).

At least that is why I always do both. Even when I create a profile with private enabled I'll still try to do both blacklist and whitelist.

Also in response to

There are 200 profiles that do include the disable-programs.inc file but don't have a whitelist rule. That basically means for those programs it hasn't been figured out yet what directories they specifically need access to—only that they shouldn't access some

Some profiles will simply never ever be whitelisted. If you whitelisted your photo viewer then you would only ever be able to view pictures in ~/Photos, what about everywhere else on your system? Same for a music player, yes some people might have music in ~/Music, but others might have an entire drive for music (or three!) or even a nas.

So please anyone reading this, don't make a PR removing blacklist from all the whitelisted profiles.

@SkewedZeppelin commented on GitHub (Sep 21, 2017): If a user wants to let a program access files in another directory and they decide to disable the whitelist in a local copy, the profile will still be restricted from reading the contents of other programs (which is good!). If blacklist wasn't included and they disabled whitelist, it'd have (near) full access to their home directory (which is very bad!). At least that is why I always do both. Even when I create a profile with `private` enabled I'll still try to do both blacklist and whitelist. Also in response to > There are 200 profiles that do include the disable-programs.inc file but don't have a whitelist rule. That basically means for those programs it hasn't been figured out yet what directories they specifically need access to—only that they shouldn't access some Some profiles will simply never ever be whitelisted. If you whitelisted your photo viewer then you would only ever be able to view pictures in ~/Photos, what about everywhere else on your system? Same for a music player, yes some people might have music in ~/Music, but others might have an entire drive for music (or three!) or even a nas. So please anyone reading this, don't make a PR removing blacklist from all the whitelisted profiles.

gitea-mirror commented

2026-05-05 07:21:07 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Sep 22, 2017):

Some profiles will simply never ever be whitelisted.

Good point. I already responded much to the same effect. Whitelisting is really good when we only need to access a (relatively) static portion of the filesystem. It's less than useful for other cases.

I like your perspective! I hadn't thought about a user taking the profile and disabling whitelists - definitely the blacklist provides a fail-safe and keeps files that really should be secret, secret. The question now is if it's worth the extra complexity to protect against this edge case. I'm tending to think that it is.

@Fred-Barclay commented on GitHub (Sep 22, 2017): > Some profiles will simply never ever be whitelisted. Good point. I already responded much to the same effect. Whitelisting is really good when we only need to access a (relatively) static portion of the filesystem. It's less than useful for other cases. I like your perspective! I hadn't thought about a user taking the profile and disabling whitelists - definitely the blacklist provides a fail-safe and keeps files that really should be secret, secret. The question now is if it's worth the extra complexity to protect against this edge case. I'm tending to think that it is.

gitea-mirror commented

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

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 22, 2017):

I think it is, but that doesn't mean we can't simplify it. Since the files that are whitelisted are usually noblacklisted adding a whitelist-noblacklisted would remove the redundancy of having both noblacklist and whitelist for a file/folder.

Example here

The gain isn't much, distribution wise text compresses extremely well, and as for installed disk space an extra 20kb savings isn't much benefit. I guess it could somewhat help with manageability of the profile however.

@SkewedZeppelin commented on GitHub (Sep 22, 2017): I think it is, but that doesn't mean we can't simplify it. Since the files that are whitelisted are usually noblacklisted adding a `whitelist-noblacklisted` would remove the redundancy of having both noblacklist and whitelist for a file/folder. Example [here](https://gist.github.com/SpotComms/885f242600575aad74a3a792cc87c472) The gain isn't much, distribution wise text compresses extremely well, and as for installed disk space an extra 20kb savings isn't much benefit. I guess it could somewhat help with manageability of the profile however.

gitea-mirror commented

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

Author

Owner

@Fred-Barclay commented on GitHub (Sep 22, 2017):

It might not save too much space but that's a really cool idea! It would also reduce the chance of typos when whitelisting a profile.

@Fred-Barclay commented on GitHub (Sep 22, 2017): It might not save too much space but that's a really cool idea! It would also reduce the chance of typos when whitelisting a profile.

gitea-mirror commented

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

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 22, 2017):

I think I've done it now, see b0ccd3ffd3. Its dependent on 12fb6c82c7.

@SkewedZeppelin commented on GitHub (Sep 22, 2017): I think I've done it now, see https://github.com/SpotComms/firejail/commit/b0ccd3ffd3bf4a8502af300e52906c539d0876b7. Its dependent on https://github.com/SpotComms/firejail/commit/12fb6c82c73a76a5587da907873e8916bafb7b46.

gitea-mirror commented

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

Author

Owner

@Fred-Barclay commented on GitHub (Sep 22, 2017):

@SpotComms Looks really good. That being said, I think it might be more logical to place whitelist-noblacklist right after the mkdir commands and just before any whitelist commands, just to keep all the whitelist operations in the same place in the profile. What do you think?

@Fred-Barclay commented on GitHub (Sep 22, 2017): @SpotComms Looks really good. That being said, I think it might be more logical to place `whitelist-noblacklist` right after the `mkdir` commands and just before any `whitelist` commands, just to keep all the whitelist operations in the same place in the profile. What do you think?

gitea-mirror commented

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

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 22, 2017):

@Fred-Barclay if whitelist-noblacklist wasn't placed where it was, it'd whitelist everything blacklisted by all of the include /etc/firejail/disable-*.inc's. Placing it anywhere else would make the code side of this much harder to implement.

Edit: I'm bad, I think we can move it to be with the rest.

@SkewedZeppelin commented on GitHub (Sep 22, 2017): @Fred-Barclay ~~if `whitelist-noblacklist` wasn't placed where it was, it'd whitelist everything blacklisted by all of the `include /etc/firejail/disable-*.inc`'s. Placing it anywhere else would make the code side of this much harder to implement.~~ Edit: I'm bad, I think we can move it to be with the rest.

gitea-mirror commented

2026-05-05 07:21:17 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Sep 22, 2017):

Would it? I was assuming that wnb would only whitelist files explicitly noblacklisted in the profile. Including blacklists shouldn't change this.

blacklist <specific files>
include some-blacklist-filter.inc
noblacklist files-that-are-needed

mkdir XYZ
whitelist-noblacklist all files that are noblacklisted
whitelist other files

@Fred-Barclay commented on GitHub (Sep 22, 2017): Would it? I was assuming that wnb would only whitelist files explicitly noblacklisted in the profile. Including blacklists shouldn't change this. ``` blacklist <specific files> include some-blacklist-filter.inc noblacklist files-that-are-needed mkdir XYZ whitelist-noblacklist all files that are noblacklisted whitelist other files ```

gitea-mirror commented

2026-05-05 07:21:18 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 22, 2017):

It wouldn't, here it is fixed 07e52cff9a

@SkewedZeppelin commented on GitHub (Sep 22, 2017): It wouldn't, here it is fixed https://github.com/SpotComms/firejail/commit/07e52cff9ac37fb675891300e300f00564d9f615

gitea-mirror commented

2026-05-05 07:21:20 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Sep 22, 2017):

I like it! Is wnb psuedo-code or do we have a working implementation?

@Fred-Barclay commented on GitHub (Sep 22, 2017): I like it! Is wnb psuedo-code or do we have a working implementation?

gitea-mirror commented

2026-05-05 07:21:21 -06:00

Author

Owner

@smitsohu commented on GitHub (Sep 22, 2017):

Hi all! Shouldn't it be easy to simply interpret whitelist also as noblacklist? I think this has been proposed already elsewhere, but I can't find it right now.

@smitsohu commented on GitHub (Sep 22, 2017): Hi all! Shouldn't it be easy to simply interpret `whitelist` also as `noblacklist`? I think this has been proposed already elsewhere, but I can't find it right now.

gitea-mirror commented

2026-05-05 07:21:22 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 22, 2017):

@Fred-Barclay We'll need someone to implement it. Just store the noblacklist paths in an array temporarily and if whitelist-noblacklist is detected to loop through the array and whitelist them.

@smitsohu that would be a different approach, but then disable-*.inc would have to be after whitelist. And again keeping the ability to disable whitelist and still have stuff blacklisted is a goal.

Edit: see the latest version here

@SkewedZeppelin commented on GitHub (Sep 22, 2017): @Fred-Barclay We'll need someone to implement it. Just store the noblacklist paths in an array temporarily and if whitelist-noblacklist is detected to loop through the array and whitelist them. @smitsohu that would be a different approach, but then disable-*.inc would have to be after whitelist. And again keeping the ability to disable whitelist and still have stuff blacklisted is a goal. Edit: see the latest version [here](https://github.com/SpotComms/firejail/commits/wnb)

gitea-mirror commented

2026-05-05 07:21:23 -06:00

Author

Owner

@smitsohu commented on GitHub (Sep 22, 2017):

@SpotComms Blacklisting files in whitelisted folders would be still possible. And even though the whitelist block could move in front of disable-*.inc and replace noblacklist there, we would keep our backwards compatibility.

The downside is indeed, that if someone decided to remove whitelisting from a profile, the fallback level would not be a safe and working blacklisted profile, as with your proposal, but a safe and broken one (this is what you meant in your previous post, right?). The "profile-ergonomics" would be worse in such a case.

@smitsohu commented on GitHub (Sep 22, 2017): @SpotComms Blacklisting files in whitelisted folders would be still possible. And even though the whitelist block could move in front of disable-*.inc and replace noblacklist there, we would keep our backwards compatibility. The downside is indeed, that if someone decided to remove whitelisting from a profile, the fallback level would not be a safe and working blacklisted profile, as with your proposal, but a safe and broken one (this is what you meant in your previous post, right?). The "profile-ergonomics" would be worse in such a case.

gitea-mirror commented

2026-05-05 07:21:25 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 22, 2017):

@smitsohu I'm a bit confused reading that, especially the last part.

Ignoring everything:

Currently profiles have either blacklist or blacklist + whitelist.
@Fred-Barclay and others on the Linux Mint forum are asking why we shouldn't just remove noblacklist and disable-programs.inc from all profiles with whitelist (eg. c307fd7691)
My response is that doing so would result in less security for the case where a user disables whitelist in a local copy of a profile
My compromise is to simply remove the redundancy of both noblacklisting and whitelisting a file/folder by introducing a new option whitelist-noblacklisted
The whitelist-noblacklisted option simply whitelists everything that was noblacklisted
A partial implementation (eg. no code) of that can be seen c04dbefdcc
Your proposal of simply having whitelist perform what noblacklist does would be bad for the same reason as 2, and would also require moving whitelist before all of the disable-*.inc's

Assuming I'm not overlooking anything there:

we would keep backwards compatibility.

Which proposal breaks backwards compatibility?

but a safe and broken one

?

The "profile-ergonomics" would be worse in such a case.

In which case?

@SkewedZeppelin commented on GitHub (Sep 22, 2017): @smitsohu I'm a bit confused reading that, especially the last part. Ignoring everything: 1. Currently profiles have either blacklist or blacklist + whitelist. 2. @Fred-Barclay and others on the Linux Mint forum are asking why we shouldn't just remove `noblacklist `and `disable-programs.inc` from all profiles with `whitelist` (eg. https://github.com/netblue30/firejail/commit/c307fd7691971923126bd1d19fb9af446eb9a2e1) 3. My response is that doing so would result in less security for the case where a user disables `whitelist` in a local copy of a profile 4. My compromise is to simply remove the redundancy of both noblacklisting and whitelisting a file/folder by introducing a new option `whitelist-noblacklisted` 5. The `whitelist-noblacklisted` option simply whitelists everything that was noblacklisted 6. A partial implementation (eg. no code) of that can be seen https://github.com/SpotComms/firejail/commit/c04dbefdccad0ab7c8a5ca237c4e16372c012d6b 7. Your proposal of simply having `whitelist` perform what `noblacklist` does would be bad for the same reason as 2, and would also require moving `whitelist` before all of the `disable-*.inc`'s Assuming I'm not overlooking anything there: > we would keep backwards compatibility. Which proposal breaks backwards compatibility? > but a safe and broken one ? > The "profile-ergonomics" would be worse in such a case. In which case?

gitea-mirror commented

2026-05-05 07:21:27 -06:00

Author

Owner

@smitsohu commented on GitHub (Sep 22, 2017):

@SpotComms sorry for being confusing (night was short). Let me try to shed some light:

to 7: No, it is neutral from a security perspective, because disable-programs.inc can be left in place. It just takes away some command atomicity (instead of noblacklist-blacklist-whitelist, it is enough to have whitelist-blacklist).... and I don't see the use case for explicitly whitelisting a blacklisted path. Note that everything else with regard to blacklisting and whitelisting is still possible.

Backwards compatibility with profiles is kept, because if the whitelist block is not moved in front of disable-*.inc, a condition noblacklist OR whitelist falls back to the old behaviour.

Disabling the whitelisting inside a profile altogether would make it necessary to rename whitelist to noblacklist. This is less ergonomic (and intuitive) than just commenting an option, and insofar your proposal is better.

I hope it is a little clearer now.

@smitsohu commented on GitHub (Sep 22, 2017): @SpotComms sorry for being confusing (night was short). Let me try to shed some light: to 7: No, it is neutral from a security perspective, because disable-programs.inc can be left in place. It just takes away some command atomicity (instead of noblacklist-blacklist-whitelist, it is enough to have whitelist-blacklist).... and I don't see the use case for explicitly whitelisting a blacklisted path. Note that everything else with regard to blacklisting and whitelisting is still possible. Backwards compatibility with profiles is kept, because if the whitelist block is not moved in front of disable-*.inc, a condition `noblacklist OR whitelist` falls back to the old behaviour. Disabling the whitelisting inside a profile altogether would make it necessary to rename whitelist to noblacklist. This is less ergonomic (and intuitive) than just commenting an option, and insofar your proposal is better. I hope it is a little clearer now.

gitea-mirror commented

2026-05-05 07:21:28 -06:00

Author

Owner

@ghost commented on GitHub (Sep 24, 2017):

Two questions:

Does the new approach means that using noblacklist ~/foo in profile would be equivalent of whitelist ~/foo? Using whitelist option in profile means that you have to do it for all needed files. What if we want to exclude only one specific file from blacklist without using whitelist approach?
As whitelists works per top directory does using noblacklist /var/foo would mean that all /var directory is in whitelist mode (see above)

BTW: why this? 5370f65d77

@ghost commented on GitHub (Sep 24, 2017): Two questions: 1. Does the new approach means that using `noblacklist ~/foo` in profile would be equivalent of `whitelist ~/foo`? Using `whitelist` option in profile means that you have to do it for all needed files. What if we want to exclude only one specific file from blacklist without using whitelist approach? 2. As whitelists works per top directory does using `noblacklist /var/foo` would mean that all `/var` directory is in whitelist mode (see above) BTW: why this? https://github.com/SpotComms/firejail/commit/5370f65d77dc618d4d750a55e9a4cfae3d891a8c

gitea-mirror commented

2026-05-05 07:21:29 -06:00

Author

Owner

@smitsohu commented on GitHub (Sep 24, 2017):

@VladimirSchowalter20 No, everything would stay the same as it is now. Except that if you put whitelist in front of blacklist, you can skip the noblacklist step.
Whitelist would imply noblacklist, not the other way round, as you put it in your comment.

But again, the proposal has its drawbacks, another one being that currently noblacklist is often only a subset of whitelist. This means that if we rewrite profiles accordingly, to some degree the transparency is lost which paths are actually blacklisted in disable-*.inc, and which paths are whitelisted only. After thinking it over, I guess I also tend to a new option instead.

@smitsohu commented on GitHub (Sep 24, 2017): @VladimirSchowalter20 No, everything would stay the same as it is now. Except that if you put whitelist in front of blacklist, you can skip the noblacklist step. Whitelist would imply noblacklist, not the other way round, as you put it in your comment. But again, the proposal has its drawbacks, another one being that currently noblacklist is often only a subset of whitelist. This means that if we rewrite profiles accordingly, to some degree the transparency is lost which paths are actually blacklisted in disable-*.inc, and which paths are whitelisted only. After thinking it over, I guess I also tend to a new option instead.

gitea-mirror commented

2026-05-05 07:21:30 -06:00

Author

Owner

@SkewedZeppelin commented on GitHub (Sep 24, 2017):

@VladimirSchowalter20

No. If a profile has noblacklist ~/foo and you want to make it whitelist instead of adding whitelist ~/foo you can simply add whitelist-noblacklist, meaning if you have 5 noblacklists instead of whitelisting each of them you can just add whitelist-noblacklist. It doesn't change any functionality of blacklist or whitelist, it would just make it easier to maintain the profile.

And 5370f65d77 was necessary for the script I made to create c04dbefdcc

@smitsohu my proposal wouldn't change anything about placement or about skipping noblacklist.

All my proposal does is remove the redundancy of whitelisting a path when it is already noblacklisted by specifying an option whitelist-noblacklisted. No more, no less.

@SkewedZeppelin commented on GitHub (Sep 24, 2017): @VladimirSchowalter20 No. If a profile has `noblacklist ~/foo` and you want to make it whitelist instead of adding `whitelist ~/foo `you can simply add `whitelist-noblacklist`, meaning if you have 5 noblacklists instead of whitelisting each of them you can just add `whitelist-noblacklist`. It doesn't change any functionality of blacklist or whitelist, it would just make it easier to maintain the profile. And https://github.com/SpotComms/firejail/commit/5370f65d77dc618d4d750a55e9a4cfae3d891a8c was necessary for the script I made to create https://github.com/SpotComms/firejail/commit/c04dbefdccad0ab7c8a5ca237c4e16372c012d6b @smitsohu my proposal wouldn't change anything about placement or about skipping noblacklist. All my proposal does is remove the redundancy of whitelisting a path when it is already noblacklisted by specifying an option `whitelist-noblacklisted`. No more, no less.

gitea-mirror commented

2026-05-05 07:21:32 -06:00

Author

Owner

@ghost commented on GitHub (Sep 24, 2017):

@smitsohu @SpotComms Thx for explanations!

@ghost commented on GitHub (Sep 24, 2017): @smitsohu @SpotComms Thx for explanations!

gitea-mirror commented

2026-05-05 07:21:33 -06:00

Author

Owner

@netblue30 commented on GitHub (Sep 25, 2017):

The idea is simple: first, we build the whitelisted filesystem, then we blacklist top secret files on the whitelisted filesystem. The order they appear in the profile is important only for "noblacklist". "whitelist" will always be done before "blacklist".

For example if you have a KDE application, you whitelist ~/.kde directory, than you blacklist ~/.kde/share/apps/kwallet.

@netblue30 commented on GitHub (Sep 25, 2017): The idea is simple: first, we build the whitelisted filesystem, then we blacklist top secret files on the whitelisted filesystem. The order they appear in the profile is important only for "noblacklist". "whitelist" will always be done before "blacklist". For example if you have a KDE application, you whitelist ~/.kde directory, than you blacklist ~/.kde/share/apps/kwallet.

gitea-mirror commented

2026-05-05 07:21:34 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Sep 28, 2017):

Thanks everyone! I think we can close this now.
@SpotComms I think whitelist-noblacklist would be awesome!

@Fred-Barclay commented on GitHub (Sep 28, 2017): Thanks everyone! I think we can close this now. @SpotComms I think whitelist-noblacklist would be awesome!

Rows
Columns

[GH-ISSUE #1569] Why do we have blacklist, noblacklist, and whitelist in the same profile? #1043