[GH-ISSUE #3447] Replace `whitelist` and `blacklist` commands with better terms

gitea-mirror commented

2026-05-05 08:50:32 -06:00

Owner

Originally created by @ClemMakesApps on GitHub (Jun 2, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3447

Since Whitelist/Blacklist have connotations about value and map to racial terms, we should replace those commands in this project with Allowlist and Denylist or something similar.

Originally created by @ClemMakesApps on GitHub (Jun 2, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3447 Since `Whitelist`/`Blacklist` have connotations about value and map to racial terms, we should replace those commands in this project with `Allowlist` and `Denylist` or something similar.

gitea-mirror

2026-05-05 08:50:32 -06:00

closed this issue
added the
enhancement
label

gitea-mirror commented

2026-05-05 08:50:35 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 3, 2020):

Are you kidding?

@netblue30 commented on GitHub (Jun 3, 2020): Are you kidding?

gitea-mirror commented

2026-05-05 08:50:36 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jun 4, 2020):

@ClemMakesApps I appreciate the concern but let's don't go down this path. Our terminology is based upon the behavior/functionality of the code, nothing more, and reflects accepted terminology. There's no need to change code which is intrinsically neutral based upon non-existent connotations to the ratio of melanin in people's skin.

@Fred-Barclay commented on GitHub (Jun 4, 2020): @ClemMakesApps I appreciate the concern but let's don't go down this path. Our terminology is based upon the behavior/functionality of the code, nothing more, and reflects accepted terminology. There's no need to change code which is intrinsically neutral based upon non-existent connotations to the ratio of melanin in people's skin.

gitea-mirror commented

2026-05-05 08:50:37 -06:00

Author

Owner

@NicoleSchwartz commented on GitHub (Jun 5, 2020):

@Fred-Barclay It doesn't matter what the original intent was. People do have a negative reaction to these terms. There is no justification for keeping it.

Over time, although you may intend them neutrally they do have negative impact. Many projects and groups have moved to the equally descriptive terms that avoid making people uncomfortable but are still equally descriptive. see https://github.com/rails/rails/issues/33677

"To compound the issue, it is also striking how often the term “whitelist” is used for a supposedly good, respectable, or safe list of publishers [20, 22, 27]. The racism in such “black is bad, white is good” metaphors is inappropriate and needs to cease. The black-white dualism explicit in these binary terms is often associated with Western thinking that is usually traced back to the work of Rene Descartes. Although the epistemological dualism of Descartes may be seen in earlier works by Plato and Aristotle, this way of thinking is often associated with the Enlightenment and the subsequent scientific revolution and industrial development [28–30]. Thus, a foundational ontological dualism accepted by many people in Western cultures includes the supposedly “natural” divides between subject-object, body-spirit, human-nature, and self-other. Such dualism extends into our conceptions of good-evil, sacred/divine-profane, and civilized-heathen/barbarian [31]." https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600/

@NicoleSchwartz commented on GitHub (Jun 5, 2020): @Fred-Barclay It doesn't matter what the original intent was. People do have a negative reaction to these terms. There is no justification for keeping it. Over time, although you may intend them neutrally they do have negative impact. Many projects and groups have moved to the equally descriptive terms that avoid making people uncomfortable but are still equally descriptive. see https://github.com/rails/rails/issues/33677 "To compound the issue, it is also striking how often the term “whitelist” is used for a supposedly good, respectable, or safe list of publishers [20, 22, 27]. The racism in such “black is bad, white is good” metaphors is inappropriate and needs to cease. The black-white dualism explicit in these binary terms is often associated with Western thinking that is usually traced back to the work of Rene Descartes. Although the epistemological dualism of Descartes may be seen in earlier works by Plato and Aristotle, this way of thinking is often associated with the Enlightenment and the subsequent scientific revolution and industrial development [28–30]. Thus, a foundational ontological dualism accepted by many people in Western cultures includes the supposedly “natural” divides between subject-object, body-spirit, human-nature, and self-other. Such dualism extends into our conceptions of good-evil, sacred/divine-profane, and civilized-heathen/barbarian [31]." https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6148600/

gitea-mirror commented

2026-05-05 08:50:38 -06:00

Author

Owner

@ghost commented on GitHub (Jun 5, 2020):

People do have a negative reaction to these terms. There is no justification for keeping it.

Some do and some don't, it's all in the 'Eye Of The Beholder'. There's no justification for not keeping it either, if this is nothing more than a plea to change a few words and call it quits. The conclusions drawn, and the subsequent (disputable) history lesson on ontological dualism feel out of place. Quoting research examining the emerging literature surrounding predatory publishing might buy one some 'social capital' (to quote another famous French male theorist), but what good does that bring besides a few likes?

Regardless of the philosophy one subscribes to (if any), I wonder if anyone here actually believes that changing terminology would make supported applications run any more secure? This project is open to PR's, which are always reviewed on their merit in relation to the goal: reducing potential privacy/security risks when using Linux applications on a daily basis. Feel free to open. Another option is forking, like glimpse-editor did for example.

@ghost commented on GitHub (Jun 5, 2020): > People do have a negative reaction to these terms. There is no justification for keeping it. Some do and some don't, it's all in the 'Eye Of The Beholder'. There's no justification for not keeping it either, if this is nothing more than a plea to change a few words and call it quits. The conclusions drawn, and the subsequent (disputable) history lesson on ontological dualism feel out of place. Quoting research examining the emerging literature surrounding `predatory publishing` might buy one some 'social capital' (to quote another famous French male theorist), but what good does that bring besides a few likes? Regardless of the philosophy one subscribes to (if any), I wonder if anyone here actually believes that changing terminology would make supported applications run any more secure? This project is open to PR's, which are always reviewed on their merit in relation to the goal: reducing potential privacy/security risks when using Linux applications on a daily basis. Feel free to open. Another option is forking, like [glimpse-editor](https://glimpse-editor.org/about/#what-if-i-find-the-word-glimpse-offensive) did for example.

gitea-mirror commented

2026-05-05 08:50:40 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 7, 2020):

noblacklist/blacklist/whitelist are the biggest challenge when learning to customize firejail-profiles. Regardless of the original idea, this is also a reasons to change them.

What is currently difficult?

blacklist ${HOME}/foo
whitelist ${HOME}/foo

~/foo is still unaccessible. (Adding whitelist ${HOME}/foo breaks everything in non-whitelisting profiles.)

include disable-baz.inc
whitelist ${HOME}/bar

In order to allow baz in this profile, you need to add noblacklist and whitelist.

My suggestion for simplifying:

blacklist -> deny (or block)
noblacklist/whitelist -> allow
whitelist -> enable-whitelisting (or require-explicit-allow)

Examples:

Old:

noblacklist ${HOME}/.cache/mozilla
noblacklist ${HOME}/.mozilla

mkdir ${HOME}/.cache/mozilla/firefox
mkdir ${HOME}/.mozilla
whitelist ${HOME}/.cache/mozilla/firefox
whitelist ${HOME}/.mozilla

New:

enable-whitelisting

mkdir ${HOME}/.cache/mozilla/firefox
mkdir ${HOME}/.mozilla
allow ${HOME}/.cache/mozilla/firefox
allow ${HOME}/.mozilla

Still uncertain

Maybe enable-whitelisting-in ${HOME}, enable-whitelisting-in /var, ... would be better.

Reasons against it

It's a breaking change.

@rusty-snake commented on GitHub (Jun 7, 2020): `noblacklist`/`blacklist`/`whitelist` are the biggest challenge when learning to customize firejail-profiles. Regardless of the original idea, this is also a reasons to change them. ### What is currently difficult? 1. ``` blacklist ${HOME}/foo whitelist ${HOME}/foo ``` `~/foo` is still unaccessible. (Adding `whitelist ${HOME}/foo` breaks everything in non-whitelisting profiles.) 2. ``` include disable-baz.inc whitelist ${HOME}/bar ``` In order to allow baz in this profile, you need to add `noblacklist` and `whitelist`. ### My suggestion for simplifying: `blacklist` -> `deny` (or `block`) `noblacklist`/`whitelist` -> `allow` `whitelist` -> `enable-whitelisting` (or `require-explicit-allow`) #### Examples: Old: ``` noblacklist ${HOME}/.cache/mozilla noblacklist ${HOME}/.mozilla mkdir ${HOME}/.cache/mozilla/firefox mkdir ${HOME}/.mozilla whitelist ${HOME}/.cache/mozilla/firefox whitelist ${HOME}/.mozilla ``` New: ``` enable-whitelisting mkdir ${HOME}/.cache/mozilla/firefox mkdir ${HOME}/.mozilla allow ${HOME}/.cache/mozilla/firefox allow ${HOME}/.mozilla ``` ### Still uncertain Maybe `enable-whitelisting-in ${HOME}`, `enable-whitelisting-in /var`, ... would be better. ### Reasons against it It's a breaking change.

gitea-mirror commented

2026-05-05 08:50:41 -06:00

Author

Owner

@topimiettinen commented on GitHub (Jun 7, 2020):

Usually in security terminology whitelist lists stuff that is only allowed, the rest is denied. This means that there's an implicit deny all directive, or it could be explicit. Likewise, with blacklist there's implicit or explicit allow all and then the list specifies denied items. In Firejail the directives doesn't match this (like @rusty-snake showed), so if there would be a change (I wouldn't be bothered to change anything just for the reasons OP gave), this could be an opportunity to improve.

@topimiettinen commented on GitHub (Jun 7, 2020): Usually in security terminology `whitelist` lists stuff that is only allowed, the rest is denied. This means that there's an implicit `deny all` directive, or it could be explicit. Likewise, with `blacklist` there's implicit or explicit `allow all` and then the list specifies denied items. In Firejail the directives doesn't match this (like @rusty-snake showed), so if there would be a change (I wouldn't be bothered to change anything just for the reasons OP gave), this could be an opportunity to improve.

gitea-mirror commented

2026-05-05 08:50:42 -06:00

Author

Owner

@kris7t commented on GitHub (Jun 7, 2020):

@rusty-snake I for one would support the blacklist -> block, noblacklist/whitelist -> allow, whitelist -> require-explicit-allow-in terminology change, so that we can clean up the confusion about noblacklist/whitelist in profiles (enable-whitelisting-in wouldn't make much sense, if there is no whitelist keyword, though).

If I understand correctly, this wouldn't really be a breaking change, since we can just interpret the original commands and emit warnings to help users with the migration. Eventually, we could deprecate blacklist/noblacklist/whitelist and achieve whitelisting profile bliss.

There could also be arguments having "whitelisting" / deny all profiles as a default (and something like implicit-allow-in to disable it), but I guess that would be a breaking change indeed.

@kris7t commented on GitHub (Jun 7, 2020): @rusty-snake I for one would support the `blacklist` -> `block`, `noblacklist`/`whitelist` -> `allow`, `whitelist` -> `require-explicit-allow-in` terminology change, so that we can clean up the confusion about `noblacklist`/`whitelist` in profiles (`enable-whitelisting-in` wouldn't make much sense, if there is no `whitelist` keyword, though). If I understand correctly, this wouldn't really be a breaking change, since we can just interpret the original commands and emit warnings to help users with the migration. Eventually, we could deprecate `blacklist`/`noblacklist`/`whitelist` and achieve whitelisting profile bliss. There could also be arguments having "whitelisting" / `deny all` profiles as a default (and something like `implicit-allow-in` to disable it), but I guess that would be a breaking change indeed.

gitea-mirror commented

2026-05-05 08:50:43 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 7, 2020):

Eventually, we could deprecate blacklist/noblacklist/whitelist and achieve whitelisting profile bliss.

👍

We can the remove nodbus and these in 0.9.66.

There could also be arguments having "whitelisting" / deny all profiles as a default (and something like implicit-allow-in to disable it), but I guess that would be a breaking change indeed.

I would favour ignore require-explicit-allow ${HOME}, using ignore seems to be the firejail-way in the most places.

BTW: such a whitelist on/off switch will be very usefull

Related issues: (mostly affected through require-explicit-allow /...)

#504: whitelist in ~/.local/share and other (mostly dotfiles) subdirs of $HOME
#3189 & #2041: whitelist in /run and others
#3041: This issue would be simplyfied
#2882: nowhitelist -> block or ignore allow ...;; This issue can be closed then, because whitelist on/off has now its own switch.

@rusty-snake commented on GitHub (Jun 7, 2020): > Eventually, we could deprecate blacklist/noblacklist/whitelist and achieve whitelisting profile bliss. :+1: We can the remove nodbus and these in 0.9.66. > There could also be arguments having "whitelisting" / deny all profiles as a default (and something like implicit-allow-in to disable it), but I guess that would be a breaking change indeed. I would favour `ignore require-explicit-allow ${HOME}`, using `ignore` seems to be the firejail-way in the most places. BTW: such a whitelist on/off switch will be very usefull --- Related issues: (mostly affected through `require-explicit-allow /...`) #504: whitelist in ~/.local/share and other (mostly dotfiles) subdirs of $HOME #3189 & #2041: whitelist in /run and others #3041: This issue would be simplyfied #2882: `nowhitelist` -> `block` or `ignore allow ...`;; This issue can be closed then, because whitelist on/off has now its own switch.

gitea-mirror commented

2026-05-05 08:50:45 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jun 7, 2020):

Sounds like some solid technical reasons for a change 😄
I would suggest we don't touch this until 0.9.64 is tagged, make the changes for 0.9.65/0.9.66, and remove in 0.9.68.

EDIT: assuming we made these changes

EDIT 2: should we reopen this issue?

@Fred-Barclay commented on GitHub (Jun 7, 2020): Sounds like some solid technical reasons for a change 😄 I would suggest we don't touch this until 0.9.64 is tagged, make the changes for 0.9.65/0.9.66, and remove in 0.9.68. EDIT: assuming we made these changes EDIT 2: should we reopen this issue?

gitea-mirror commented

2026-05-05 08:50:46 -06:00

Author

Owner

@ClemMakesApps commented on GitHub (Jun 8, 2020):

I wouldn't be bothered to change anything just for the reasons OP gave

It's a shame that the original premise wasn't deemed sufficient enough for a change but I'm glad this change is still happening even if it is for another reason.

@ClemMakesApps commented on GitHub (Jun 8, 2020): > I wouldn't be bothered to change anything just for the reasons OP gave It's a shame that the original premise wasn't deemed sufficient enough for a change but I'm glad this change is still happening even if it is for another reason.

gitea-mirror commented

2026-05-05 08:50:47 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 8, 2020):

EDIT 2: should we reopen this issue?

I would say yes.

@rusty-snake commented on GitHub (Jun 8, 2020): > EDIT 2: should we reopen this issue? I would say yes.

gitea-mirror commented

2026-05-05 08:50:47 -06:00

Author

Owner

@Fred-Barclay commented on GitHub (Jun 8, 2020):

@ClemMakesApps Thanks for bringing it to our attention! Even if we disagree on the premises it seems a change was needed 😄

@Fred-Barclay commented on GitHub (Jun 8, 2020): @ClemMakesApps Thanks for bringing it to our attention! Even if we disagree on the premises it seems a change was needed :smile:

gitea-mirror commented

2026-05-05 08:50:48 -06:00

Author

Owner

@netblue30 commented on GitHub (Jun 13, 2020):

Let's wait for a while to see in what direction the big guys are going, so we don't have to change it again in a few months. Whitelist/blacklist are heavily used in various places:

networking industry: email infrastructure and firewall people. If you tell them allow/deny they have no idea what you are talking about
mandatory access control (SELinux, AppArmor) - the terms have been there for more than 20 years
mass media: a search on news google.com shows CNN, ABC News, vox.com and a lot more.
the advertising industry: apparently adblockers are "blacklisting" them!

@netblue30 commented on GitHub (Jun 13, 2020): Let's wait for a while to see in what direction the big guys are going, so we don't have to change it again in a few months. Whitelist/blacklist are heavily used in various places: * networking industry: email infrastructure and firewall people. If you tell them allow/deny they have no idea what you are talking about * mandatory access control (SELinux, AppArmor) - the terms have been there for more than 20 years * mass media: a search on news google.com shows CNN, ABC News, vox.com and a lot more. * the advertising industry: apparently adblockers are "blacklisting" them!

gitea-mirror commented

2026-05-05 08:50:49 -06:00

Author

Owner

@topimiettinen commented on GitHub (Jun 14, 2020):

With allow/deny I was thinking about Apache config (Order Allow, Deny; Deny from x; Allow from y) but it seems that modern 2.4 syntax uses Require.

Examples from similar, rather old (1990s) software using allow and deny:

OpenSSH uses AllowGroup, AllowUser, DenyGroup, DenyUser.
TCP Wrappers have two files, /etc/hosts.allow and /etc/hosts.deny.

MAC systems:

In AppArmor, the rules list allowed conditions without a keyword. There's an explicit deny keyword.
SELinux has allow keyword (everything not allowed is forbidden). There's also neverallow but it's more like assert() function in C.
Smack does not use English keywords.
With TOMOYO Linux there are no explicit allow/deny keywords, the rules just list all allowed conditions.

Firewalls:

Iptables and Shorewall use ACCEPT, DROP and REJECT.
NFTables uses accept, drop and reject.
Firewalld uses XML, so the keywords are <accept>, <drop> and <reject>.
Ubuntu UFW uses allow and deny.
Cisco IOS firewall access rules use permit and deny.

IMHO white and black are used in white/blacklists without much of a preference, both are "good" and the "evil" is not using either. Whitelisting is preferred in many cases, but there are also situations where blacklisting is better.

@topimiettinen commented on GitHub (Jun 14, 2020): With `allow/deny` I was thinking about Apache config (`Order Allow, Deny; Deny from x; Allow from y`) but it seems that [modern 2.4 syntax](http://httpd.apache.org/docs/2.4/howto/access.html) uses `Require`. Examples from similar, rather old (1990s) software using `allow` and `deny`: * [OpenSSH](https://man.openbsd.org/sshd_config) uses `AllowGroup, AllowUser, DenyGroup, DenyUser`. * [TCP Wrappers](https://www.freebsd.org/doc/handbook/tcpwrappers.html) have two files, `/etc/hosts.allow` and `/etc/hosts.deny`. MAC systems: * In [AppArmor](https://gitlab.com/apparmor/apparmor/-/wikis/QuickProfileLanguage), the rules list allowed conditions without a keyword. There's an explicit `deny` keyword. * [SELinux](https://selinuxproject.org/page/AVCRule) has `allow` keyword (everything not allowed is forbidden). There's also `neverallow` but it's more like `assert()` function in C. * [Smack](https://www.kernel.org/doc/html/latest/admin-guide/LSM/Smack.html) does not use English keywords. * With [TOMOYO Linux](https://tomoyo.osdn.jp/2.6/policy-specification/index.html.en) there are no explicit allow/deny keywords, the rules just list all allowed conditions. Firewalls: * [Iptables](https://linux.die.net/man/8/iptables) and [Shorewall](https://shorewall.org/manpages/shorewall-rules.html) use `ACCEPT`, `DROP` and `REJECT`. * [NFTables](https://wiki.nftables.org/wiki-nftables/index.php/Accepting_and_dropping_packets) uses `accept`, `drop` and [reject](https://wiki.nftables.org/wiki-nftables/index.php/Rejecting_traffic). * [Firewalld](https://firewalld.org/documentation/man-pages/firewalld.zone.html) uses XML, so the keywords are `<accept>`, `<drop>` and `<reject>`. * Ubuntu [UFW](https://help.ubuntu.com/community/UFW) uses `allow` and `deny`. * [Cisco IOS firewall access rules](https://www.cisco.com/c/en/us/td/docs/security/asa/asa96/configuration/firewall/asa-96-firewall-config/access-rules.html) use `permit` and `deny`. IMHO white and black are used in white/blacklists without much of a preference, both are "good" and the "evil" is not using either. Whitelisting is preferred in many cases, but there are also situations where blacklisting is better.

gitea-mirror commented

2026-05-05 08:50:49 -06:00

Author

Owner

@ghost commented on GitHub (Jun 14, 2020):

Now this. It's going to be a hell of a summer this time around...

@ghost commented on GitHub (Jun 14, 2020): Now [this](https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/). It's going to be a hell of a summer this time around...

gitea-mirror commented

2026-05-05 08:50:49 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 14, 2020):

https://tools.ietf.org/html/draft-knodel-terminology-01
https://bugs.python.org/issue34605

@rusty-snake commented on GitHub (Jun 14, 2020): https://tools.ietf.org/html/draft-knodel-terminology-01 https://bugs.python.org/issue34605

gitea-mirror commented

2026-05-05 08:50:50 -06:00

Author

Owner

@laniakea64 commented on GitHub (Jul 19, 2020):

noblacklist/blacklist/whitelist are the biggest challenge when learning to customize firejail-profiles.

As someone who has written firejail profiles since firejail 0.9.38 and STILL sometimes gets tripped up by this, if I could expand on @rusty-snake suggestion above?

I'm glad something will be done about that. Though I have few technical concerns about the current suggestion as-is. For one, I'm not sure require-explicit-allow-in accurately describes that functionality: require-explicit-allow-in seems to say that the files and directories will be there-but-blocked by default. But in reality they are completely absent and their paths are not banned by default.

And IIUC the suggestion above would take away the possibility provided by current blacklist + whitelist: to deliberately expose a file or directory in the sandbox while denying access to it. I had this as part of my setup when I had multiple profiles for SeaMonkey, with a different firejail profile for each SeaMonkey profile.

So here's a tweak of @rusty-snake suggestion that would

alleviate the confusion in writing profiles, as already proposed;
not reduce possibilities.

blacklist -> deny
noblacklist + whitelist -> allow
noblacklist alone -> ignore deny
whitelist alone -> expose

And the new directive to enable the functionality currently called "whitelisting": default-mask.

(I would think expose would have no effect where no default-mask directive is applied. Not sure what's best for allow in that case, should it be equivalent to ignore deny?)

Taking the example above:

Old:

noblacklist ${HOME}/.cache/mozilla
noblacklist ${HOME}/.mozilla

mkdir ${HOME}/.cache/mozilla/firefox
mkdir ${HOME}/.mozilla
whitelist ${HOME}/.cache/mozilla/firefox
whitelist ${HOME}/.mozilla

Suggested: there would be two ways to do this -

default-mask ${HOME}

mkdir ${HOME}/.cache/mozilla/firefox
mkdir ${HOME}/.mozilla
allow ${HOME}/.cache/mozilla/firefox
allow ${HOME}/.mozilla

or

default-mask ${HOME}

ignore deny ${HOME}/.cache/mozilla
ignore deny ${HOME}/.mozilla

mkdir ${HOME}/.cache/mozilla/firefox
mkdir ${HOME}/.mozilla
expose ${HOME}/.cache/mozilla/firefox
expose ${HOME}/.mozilla

@laniakea64 commented on GitHub (Jul 19, 2020): > `noblacklist`/`blacklist`/`whitelist` are the biggest challenge when learning to customize firejail-profiles. As someone who has written firejail profiles since firejail 0.9.38 and STILL sometimes gets tripped up by this, if I could expand on @rusty-snake suggestion above? I'm glad something will be done about that. Though I have few technical concerns about the current suggestion as-is. For one, I'm not sure `require-explicit-allow-in` accurately describes that functionality: `require-explicit-allow-in` seems to say that the files and directories will be there-but-blocked by default. But in reality they are **completely absent** and their paths are **not banned** by default. And IIUC the suggestion above would take away the possibility provided by current `blacklist` + `whitelist`: to _deliberately_ expose a file or directory in the sandbox while denying access to it. I had this as part of my setup when I had multiple profiles for SeaMonkey, with a different firejail profile for each SeaMonkey profile. So here's a tweak of @rusty-snake suggestion that would - alleviate the confusion in writing profiles, as already proposed; - not reduce possibilities. `blacklist` -> **`deny`** `noblacklist` + `whitelist` -> **`allow`** `noblacklist` alone -> **`ignore deny`** `whitelist` alone -> **`expose`** And the new directive to enable the functionality currently called "whitelisting": **`default-mask`**. (I would think `expose` would have no effect where no `default-mask` directive is applied. Not sure what's best for `allow` in that case, should it be equivalent to `ignore deny`?) ------------------- Taking the example above: > Old: > > ``` > noblacklist ${HOME}/.cache/mozilla > noblacklist ${HOME}/.mozilla > > mkdir ${HOME}/.cache/mozilla/firefox > mkdir ${HOME}/.mozilla > whitelist ${HOME}/.cache/mozilla/firefox > whitelist ${HOME}/.mozilla > ``` Suggested: there would be two ways to do this - ``` default-mask ${HOME} mkdir ${HOME}/.cache/mozilla/firefox mkdir ${HOME}/.mozilla allow ${HOME}/.cache/mozilla/firefox allow ${HOME}/.mozilla ``` or ``` default-mask ${HOME} ignore deny ${HOME}/.cache/mozilla ignore deny ${HOME}/.mozilla mkdir ${HOME}/.cache/mozilla/firefox mkdir ${HOME}/.mozilla expose ${HOME}/.cache/mozilla/firefox expose ${HOME}/.mozilla ```

gitea-mirror commented

2026-05-05 08:50:50 -06:00

Author

Owner

@Boruch-Baum commented on GitHub (Jul 23, 2020):

Add VMware to the list of major players seeing fit to step up.

@Boruch-Baum commented on GitHub (Jul 23, 2020): Add VMware to the list of major players seeing fit to [step up](https://go.theregister.com/feed/www.theregister.com/2020/07/23/vmware_offensive_terminology_style_guide).

gitea-mirror commented

2026-05-05 08:50:50 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 30, 2020):

I recently thought about @laniakea64 ideas in https://github.com/netblue30/firejail/issues/3447#issuecomment-660569123. Based on this I extend my https://github.com/netblue30/firejail/issues/3447#issuecomment-640246145 draft with

deny-expose/deny-exposed with makes a file present but inaccessible in whitelisting-profiles.
enable-whitelisting/require-explicit-allow -> mask ${HOME} it is much shorter, also talking about masked-profiles is clearer.
blacklist-nolog->deny-nolog

About the implementation version. firejail 0.9.64 should not have it, it should be released in the next week (but not before the appimage bug is fixed).

Then we can implement it. I have no problem when we replace it without backward-compatibility. And provide a transition-script/flag. We can then move from a felt 0.9.VERSION[.PATCH] version-shema to firejail 1.0 🎆 .

@rusty-snake commented on GitHub (Aug 30, 2020): I recently thought about @laniakea64 ideas in https://github.com/netblue30/firejail/issues/3447#issuecomment-660569123. Based on this I extend my https://github.com/netblue30/firejail/issues/3447#issuecomment-640246145 draft with - `deny-expose`/`deny-exposed` with makes a file present but inaccessible in whitelisting-profiles. - `enable-whitelisting`/`require-explicit-allow` -> `mask ${HOME}` it is much shorter, also talking about masked-profiles is clearer. - `blacklist-nolog`->`deny-nolog` ---- About the implementation version. firejail 0.9.64 should not have it, it should be released in the next week (but not before the appimage bug is fixed). Then we can implement it. I have no problem when we replace it without backward-compatibility. And provide a transition-script/flag. We can then move from a felt 0.9.VERSION[.PATCH] version-shema to firejail 1.0 :fireworks: .

gitea-mirror commented

2026-05-05 08:50:51 -06:00

Author

Owner

@topimiettinen commented on GitHub (Aug 30, 2020):

+1 for mask. How about unmask/deny-unmask instead of expose/deny-expose then?

@topimiettinen commented on GitHub (Aug 30, 2020): +1 for `mask`. How about `unmask/deny-unmask` instead of `expose/deny-expose` then?

gitea-mirror commented

2026-05-05 08:50:51 -06:00

Author

Owner

@rusty-snake commented on GitHub (Aug 30, 2020):

So where are we?

allow ${HOME}/foo: access to $HOME/foo is always allowed
deny ${HOME}/bar: access to $HOME/bar is always denied

If a file has a allow and a deny rule, the first will win (i.e. later rules are ignored). This is necessary for .local-overrides to work.

mask ${HOME}: mount a tmpfs over $HOME and bind-mount allowed files.
TODO: Does mask need restrictions?

deny-exposed ${HOME}/foobar: access to $HOME/foobar is denied, but $HOME is visible if mask is used.
I don't care if we call it deny-expose(d) or deny-unmask. unmask sound more as it is related to mask and not deny.

In addition:

Why do we need mkdir + whitelist all the time?
Proposal: allow implies mkdir if mask is used. A allow-nocreate can be used to opt-out.

Examples:

Old:

noblacklist ${HOME}/.config/mpv
blacklist /tmp/.X11-unix
blacklist ${HOME}/.config/mpv -- include disable-programs.inc

mkdir ${HOME}/.config/mpv
whitelist ${HOME}/.config/mpv
whitelist ${DOWNLOADS}

New:

mask ${HOME}
allow ${HOME}/.config/mpv
allow-nocreate ${DOWNLOADS}
deny /tmp/.X11-unix
deny ${HOME}/.config/mpv -- include disable-programs.inc

@rusty-snake commented on GitHub (Aug 30, 2020): So where are we? `allow ${HOME}/foo`: access to $HOME/foo is always allowed `deny ${HOME}/bar`: access to $HOME/bar is always denied If a file has a `allow` and a `deny` rule, the first will win (i.e. later rules are ignored). This is necessary for .local-overrides to work. `mask ${HOME}`: mount a tmpfs over $HOME and bind-mount allowed files. TODO: Does `mask` need restrictions? `deny-exposed ${HOME}/foobar`: access to $HOME/foobar is denied, but $HOME is visible if `mask` is used. I don't care if we call it `deny-expose(d)` or `deny-unmask`. `unmask` sound more as it is related to mask and not deny. In addition: Why do we need `mkdir` + `whitelist` all the time? Proposal: `allow` implies `mkdir` if `mask` is used. A `allow-nocreate` can be used to opt-out. Examples: Old: ``` noblacklist ${HOME}/.config/mpv blacklist /tmp/.X11-unix blacklist ${HOME}/.config/mpv -- include disable-programs.inc mkdir ${HOME}/.config/mpv whitelist ${HOME}/.config/mpv whitelist ${DOWNLOADS} ``` New: ``` mask ${HOME} allow ${HOME}/.config/mpv allow-nocreate ${DOWNLOADS} deny /tmp/.X11-unix deny ${HOME}/.config/mpv -- include disable-programs.inc ```

gitea-mirror commented

2026-05-05 08:50:52 -06:00

Author

Owner

@laniakea64 commented on GitHub (Aug 31, 2020):

Why do we need mkdir + whitelist all the time?
Proposal: allow implies mkdir if mask is used. A allow-nocreate can be used to opt-out.

I see this could be helpful for the typical case. But wouldn't it be confusing if someone wanted to allow a file that does not yet exist?

With the current proposal, that would look like -

mkfile ~/.hgrc
allow-nocreate ~/.hgrc

That confusion could be alleviated by, in addition to allow and allow-nocreate, also having an allow-file directive to imply mkfile instead of mkdir on non-existant where mask is used.

@laniakea64 commented on GitHub (Aug 31, 2020): > Why do we need `mkdir` + `whitelist` all the time? > Proposal: `allow` implies `mkdir` if `mask` is used. A `allow-nocreate` can be used to opt-out. I see this could be helpful for the typical case. But wouldn't it be confusing if someone wanted to allow a _file_ that does not yet exist? With the current proposal, that would look like - ``` mkfile ~/.hgrc allow-nocreate ~/.hgrc ``` That confusion could be alleviated by, in addition to `allow` and `allow-nocreate`, also having an `allow-file` directive to imply `mkfile` instead of `mkdir` on non-existant where `mask` is used.

gitea-mirror commented

2026-05-05 08:50:52 -06:00

Author

Owner

@rusty-snake commented on GitHub (Oct 22, 2020):

or we use allow/allow-dir and allow-file and allow-nocreate (we need this for e.g. socktes).

Now 0.9.64 is out. Let's go.

@rusty-snake commented on GitHub (Oct 22, 2020): or we use `allow`/`allow-dir` and `allow-file` and `allow-nocreate` (we need this for e.g. socktes). Now 0.9.64 is out. Let's go.

gitea-mirror commented

2026-05-05 08:50:53 -06:00

Author

Owner

@smitsohu commented on GitHub (Nov 19, 2020):

There is now an industry wide effort

https://inclusivenaming.org/

@smitsohu commented on GitHub (Nov 19, 2020): There is now an industry wide effort https://inclusivenaming.org/

gitea-mirror commented

2026-05-05 08:50:53 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 7, 2020):

I'll add this one from Linux kernel:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

+For symbol names and documentation, avoid introducing new usage of
+'master / slave' (or 'slave' independent of 'master') and 'blacklist /
+whitelist'.
+
+Recommended replacements for 'master / slave' are:
+    '{primary,main} / {secondary,replica,subordinate}'
+    '{initiator,requester} / {target,responder}'
+    '{controller,host} / {device,worker,proxy}'
+    'leader / follower'
+    'director / performer'
+
+Recommended replacements for 'blacklist/whitelist' are:
+    'denylist / allowlist'
+    'blocklist / passlist'
+
+Exceptions for introducing new usage is to maintain a userspace ABI/API,
+or when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications
+translate specification usage of the terminology to the kernel coding
+standard where possible.

@netblue30 commented on GitHub (Dec 7, 2020): I'll add this one from Linux kernel: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb ````` +For symbol names and documentation, avoid introducing new usage of +'master / slave' (or 'slave' independent of 'master') and 'blacklist / +whitelist'. + +Recommended replacements for 'master / slave' are: + '{primary,main} / {secondary,replica,subordinate}' + '{initiator,requester} / {target,responder}' + '{controller,host} / {device,worker,proxy}' + 'leader / follower' + 'director / performer' + +Recommended replacements for 'blacklist/whitelist' are: + 'denylist / allowlist' + 'blocklist / passlist' + +Exceptions for introducing new usage is to maintain a userspace ABI/API, +or when updating code for an existing (as of 2020) hardware or protocol +specification that mandates those terms. For new specifications +translate specification usage of the terminology to the kernel coding +standard where possible. `````

gitea-mirror commented

2026-05-05 08:50:53 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 8, 2021):

Before I forget it again to comment. The noblacklist|whitelist -> allow change must work like this.

old:

# thunderbird.profile
noblacklist ${HOME}/.mozilla
whitelist ${HOME}/.mozilla/firefox/profiles.ini
read-only ${HOME}/.mozilla/firefox/profiles.ini
# disable-programs.inc
blacklist ${HOME}/.mozilla

new:

# thunderbird.profile
mask ${HOME}
allow ${HOME}/.mozilla/firefox/profiles.ini
read-only ${HOME}/.mozilla/firefox/profiles.ini
# disable-programs.inc
deny ${HOME}/.mozilla

@rusty-snake commented on GitHub (Jan 8, 2021): Before I forget it again to comment. The `noblacklist`|`whitelist` -> `allow` change must work like this. old: ``` # thunderbird.profile noblacklist ${HOME}/.mozilla whitelist ${HOME}/.mozilla/firefox/profiles.ini read-only ${HOME}/.mozilla/firefox/profiles.ini # disable-programs.inc blacklist ${HOME}/.mozilla ``` new: ``` # thunderbird.profile mask ${HOME} allow ${HOME}/.mozilla/firefox/profiles.ini read-only ${HOME}/.mozilla/firefox/profiles.ini # disable-programs.inc deny ${HOME}/.mozilla ```

gitea-mirror commented

2026-05-05 08:50:54 -06:00

Author

Owner

@netblue30 commented on GitHub (Jul 1, 2021):

Moving the discussion here: https://github.com/netblue30/firejail/issues/4379

@netblue30 commented on GitHub (Jul 1, 2021): Moving the discussion here: https://github.com/netblue30/firejail/issues/4379

gitea-mirror commented

2026-05-05 08:50:54 -06:00

Author

Owner

@samuelfmlourenco commented on GitHub (Feb 18, 2022):

This is unproductive and very subjective. My two cents: it will lead to confusion and to configurations that will no longer work after the update. If this is a real issue, then you should release a major version, because it will not be backwards compatible with legacy config scripts.

@samuelfmlourenco commented on GitHub (Feb 18, 2022): This is unproductive and very subjective. My two cents: it will lead to confusion and to configurations that will no longer work after the update. If this is a real issue, then you should release a major version, because it will not be backwards compatible with legacy config scripts.

gitea-mirror referenced this issue

2026-05-05 10:15:29 -06:00

[PR #2165] [MERGED] Authenticator #4194

Rows
Columns

[GH-ISSUE #3447] Replace whitelist and blacklist commands with better terms #2165

What is currently difficult?

My suggestion for simplifying:

Examples:

Still uncertain

Reasons against it

[GH-ISSUE #3447] Replace `whitelist` and `blacklist` commands with better terms #2165