[GH-ISSUE #1743] Can't combine --private with --whitelist

gitea-mirror commented

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

Owner

Originally created by @eevee on GitHub (Jan 20, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1743

With --private=DIR, I can replace my entire home directory with a persistent substitute. With --whitelist=DIR, I can preserve part of my home directory while hiding everything else. But there doesn't seem to be any way to combine these behaviors — e.g., if I want to run a game (which needs all its data files to exist) and still let it write out a save file to some undocumented place elsewhere in my home directory.

This is also troublesome for writing a flexible general-purpose profile. If I put private in the profile, then I can't use --whitelist on the command line at all; if I don't put private in the profile, then if I don't use --whitelist on the command line my entire home directory remains exposed.

In general it would be nice if --private, --whitelist, and --overlay had clearer interactions with each other.

Relates to:

#6513

Originally created by @eevee on GitHub (Jan 20, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1743 With `--private=DIR`, I can replace my entire home directory with a persistent substitute. With `--whitelist=DIR`, I can preserve _part_ of my home directory while hiding everything else. But there doesn't seem to be any way to combine these behaviors — e.g., if I want to run a game (which needs all its data files to exist) and still let it write out a save file to some undocumented place elsewhere in my home directory. This is also troublesome for writing a flexible general-purpose profile. If I put `private` in the profile, then I can't use `--whitelist` on the command line at all; if I _don't_ put `private` in the profile, then if I don't use `--whitelist` on the command line my entire home directory remains exposed. In general it would be nice if `--private`, `--whitelist`, and `--overlay` had clearer interactions with each other. Relates to: * #6513

gitea-mirror

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

closed this issue
added the
wontfix
label

gitea-mirror commented

2026-05-05 07:36:38 -06:00

Author

Owner

@netblue30 commented on GitHub (Jan 27, 2018):

I started adding support for it. So far I have: private-dev, private-tmp and whitelist support for --overlay and --chroot sandboxes. You can try it out.

Support for --private=dir and --private-home is coming soon.

@netblue30 commented on GitHub (Jan 27, 2018): I started adding support for it. So far I have: private-dev, private-tmp and whitelist support for --overlay and --chroot sandboxes. You can try it out. Support for --private=dir and --private-home is coming soon.

gitea-mirror commented

2026-05-05 07:36:40 -06:00

Author

Owner

@qutetemp commented on GitHub (Feb 3, 2018):

whitelist support for --overlay and --chroot sandboxes. You can try it out.

Do I need the latest master because it doesn't seem to work.

@qutetemp commented on GitHub (Feb 3, 2018): >whitelist support for --overlay and --chroot sandboxes. You can try it out. Do I need the latest master because it doesn't seem to work.

gitea-mirror commented

2026-05-05 07:36:42 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 3, 2018):

Yes, it is only in master. Also, there are some more general fixes related to overlay there. It will go into the next release.

@netblue30 commented on GitHub (Feb 3, 2018): Yes, it is only in master. Also, there are some more general fixes related to overlay there. It will go into the next release.

gitea-mirror commented

2026-05-05 07:36:43 -06:00

Author

Owner

@Ninlives commented on GitHub (Aug 8, 2018):

What's the status for whitelist support for --private now?

@Ninlives commented on GitHub (Aug 8, 2018): What's the status for whitelist support for --private now?

gitea-mirror commented

2026-05-05 07:36:45 -06:00

Author

Owner

@H8to commented on GitHub (Sep 28, 2018):

Also hoping for this feature!
I use firejail as a Firefox profile template engine. For each of my customers the customer-template jail from a fully configured Firefox is copied to "customer-n", which then should be used for customer stuff (--private=customer-n). However I'd like to access e.g. downloads with other applications and this leads to problems as I cannot whitelist paths outside of the jail. Also copying from within the jailed Firefox is not possible as long as I can't whitelist my home/x/Desktop path.

@H8to commented on GitHub (Sep 28, 2018): Also hoping for this feature! I use firejail as a Firefox profile template engine. For each of my customers the customer-template jail from a fully configured Firefox is copied to "customer-n", which then should be used for customer stuff (--private=customer-n). However I'd like to access e.g. downloads with other applications and this leads to problems as I cannot whitelist paths outside of the jail. Also copying from within the jailed Firefox is not possible as long as I can't whitelist my home/x/Desktop path.

gitea-mirror commented

2026-05-05 07:36:47 -06:00

Author

Owner

@Vincent43 commented on GitHub (Sep 28, 2018):

Perhaps it's not complete solution for you but it's possible to transfer files from/to --private sandbox with --get/--put options. See FILE TRANSFER section in manpage.

@Vincent43 commented on GitHub (Sep 28, 2018): Perhaps it's not complete solution for you but it's possible to transfer files from/to `--private` sandbox with `--get`/`--put` options. See `FILE TRANSFER` section in manpage.

gitea-mirror commented

2026-05-05 07:36:48 -06:00

Author

Owner

@H8to commented on GitHub (Sep 28, 2018):

Thank you for your suggestion, I read through it!

I know that's not really the point of a private "jail", but I'd like to be able to download something in the jailed Firefox and then move it to a folder that's shared with the jail via drag and drop. This is the most comforty option. Put and get are demanding to much effort as I could also then just open Nemo and dragNdrop the files or folders from the jail home/downloads folder.

@H8to commented on GitHub (Sep 28, 2018): Thank you for your suggestion, I read through it! I know that's not really the point of a private "jail", but I'd like to be able to download something in the jailed Firefox and then move it to a folder that's shared with the jail via drag and drop. This is the most comforty option. Put and get are demanding to much effort as I could also then just open Nemo and dragNdrop the files or folders from the jail home/downloads folder.

gitea-mirror commented

2026-05-05 07:36:49 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Sep 28, 2018):

@H8to I actually have a similar system for so-called "ephemeral profiles". The script is in my Firejail Profiles repo and is called firefox.common. If you don't want firefox to be able to access other profiles, you can just use a --whitelist command to whitelist only that specific profile instead of whitelisting ~/.mozilla/firefox [edit: the script does this by default now!]. You could probably adapt a simpler version of the script for your use.

@chiraag-nataraj commented on GitHub (Sep 28, 2018): @H8to I actually have a similar system for so-called "ephemeral profiles". The script is in my [Firejail Profiles](https://github.com/chiraag-nataraj/firejail-profiles) repo and is called `firefox.common`. If you don't want `firefox` to be able to access other profiles, you can just use a `--whitelist` command to whitelist only that specific profile instead of whitelisting `~/.mozilla/firefox` [edit: the script does this by default now!]. You could probably adapt a simpler version of the script for your use.

gitea-mirror commented

2026-05-05 07:36:51 -06:00

Author

Owner

@Vincent43 commented on GitHub (Sep 28, 2018):

Also making --whitelist compatible with --private is not that easy. Currently --private can be used on top of any existent profile and it always give you separated and temporary $HOME regardless of what rules specific profile contains. If we make it compatible then suddenly all --whitelist rules existent in profile will take effect which make --private not effective. Perhaps separated option like --private-whitelist may be used if anything to no break existing usage.

@Vincent43 commented on GitHub (Sep 28, 2018): Also making `--whitelist` compatible with `--private` is not that easy. Currently `--private` can be used on top of any existent profile and it always give you separated and temporary `$HOME` regardless of what rules specific profile contains. If we make it compatible then suddenly all `--whitelist` rules existent in profile will take effect which make `--private` not effective. Perhaps separated option like `--private-whitelist` may be used if anything to no break existing usage.

gitea-mirror commented

2026-05-05 07:36:52 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Sep 28, 2018):

To add to that, more fundamentally, a "private" jail is not meant to share data with other jails or the host. That's the whole point of a private jail. It's basically meant to act as a chroot for your home directory (which can be set-up by a regular user). If you want to share data, you're probably better off figuring out a solution with whitelist and scripts (such as the firefox.common script I alluded to in my previous reply).

@chiraag-nataraj commented on GitHub (Sep 28, 2018): To add to that, more fundamentally, a "private" jail is not _meant_ to share data with other jails or the host. That's the whole point of a private jail. It's basically meant to act as a chroot for your home directory (which can be set-up by a regular user). If you want to share data, you're probably better off figuring out a solution with `whitelist` and scripts (such as the `firefox.common` script I alluded to in my previous reply).

gitea-mirror commented

2026-05-05 07:36:53 -06:00

Author

Owner

@Vincent43 commented on GitHub (Sep 28, 2018):

Yeah, I fully agree. Should we close this as wontfix? 😄

@Vincent43 commented on GitHub (Sep 28, 2018): Yeah, I fully agree. Should we close this as wontfix? :smile:

gitea-mirror commented

2026-05-05 07:36:54 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Sep 28, 2018):

@Vincent43 Let's close it for now. If it seems like there is a legimate reason to reconsider it, we'll re-open it.

@chiraag-nataraj commented on GitHub (Sep 28, 2018): @Vincent43 Let's close it for now. If it seems like there is a legimate reason to reconsider it, we'll re-open it.

gitea-mirror commented

2026-05-05 07:36:55 -06:00

Author

Owner

@modelfe commented on GitHub (Jul 25, 2019):

I'm not sure I understand the reasoning for the wontfix here.

In my case, I'm using a firejailed Firefox browser profile for my work. Using --private=~/work is super useful, as it allows me to have a persistent Firefox browser profile setup, while isolating the browser from everything outside the work directory. However, I have a large number of media files in a directory on a separate HDD that I'd like to be able to regularly access from this Firefox profile. Being able to simply whitelist the desired media directory so I could access it would be enormously useful.

Please consider somehow adding this functionality.

@modelfe commented on GitHub (Jul 25, 2019): I'm not sure I understand the reasoning for the wontfix here. In my case, I'm using a firejailed Firefox browser profile for my work. Using --private=~/work is super useful, as it allows me to have a persistent Firefox browser profile setup, while isolating the browser from everything outside the work directory. However, I have a large number of media files in a directory on a separate HDD that I'd like to be able to regularly access from this Firefox profile. Being able to simply whitelist the desired media directory so I could access it would be enormously useful. Please consider somehow adding this functionality.

gitea-mirror commented

2026-05-05 07:36:56 -06:00

Author

Owner

@modelfe commented on GitHub (Jul 26, 2019):

To follow up on my last post; it turns out it actually is possible to do this by whitelisting the media directory in a custom firejail profile. But whitelisting the same directory with --whitelist does not work.

So including whitelist /media/<username>/work_media in a custom firejail profile works, even when launching with --private=~/work
But launching with --whitelist=/media/<username>/work_media does not.

Is there a reason for this inconsistency, or is this a bug?

@modelfe commented on GitHub (Jul 26, 2019): To follow up on my last post; it turns out it actually is possible to do this by whitelisting the media directory in a custom firejail profile. But whitelisting the same directory with --whitelist does **not** work. So including `whitelist /media/<username>/work_media` in a custom firejail profile works, even when launching with --private=~/work But launching with `--whitelist=/media/<username>/work_media` does not. Is there a reason for this inconsistency, or is this a bug?

gitea-mirror commented

2026-05-05 07:36:56 -06:00

Author

Owner

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

@modelfe --private "breaks" whitelisting only in $HOME.

Is there a reason for this inconsistency, or is this a bug?

If you for example run firejail --whitelist=/media/<username>/work_media firefox, firejail will load the firejail profile which contains disable-mnt. disable-mnt blacklists /mnt, /media, ... .You can try adding --noprofile or --ignore=disable-mnt.

@rusty-snake commented on GitHub (Jul 26, 2019): @modelfe `--private` "breaks" `whitelist`ing only in $HOME. > Is there a reason for this inconsistency, or is this a bug? If you for example run `firejail --whitelist=/media/<username>/work_media firefox`, firejail will load the firejail profile which contains `disable-mnt`. `disable-mnt` `blacklist`s `/mnt`, `/media`, ... .You can try adding `--noprofile` or `--ignore=disable-mnt`.

gitea-mirror commented

2026-05-05 07:36:58 -06:00

Author

Owner

@3ThumbsUp commented on GitHub (Jan 13, 2022):

I'd like to voice support for this feature.

One of my use cases is that I use firejail with Steam. As Steam seems to clutter the home directory more than any other program, I've given it its own firejailed home. That way Steam can do whatever it wants to, and all the clutter is out of my way in a separate directory. However, this limits some of the features. For example, I would still like Steam to be able to create desktop shortcuts, but for this to work, it needs access to /usr/share/applications and /usr/share/icons in the real home directory. Ideally, I would like it to have a firejailed home for all directories except those.

The same argument goes for some proprietary video editing software (Davinci Resolve in my case). I want to give it its own home directory to not clutter my personal home, but it obviously still needs access to my Video directory. And I can't just use regular whitelists without private mode, because the files it creates are still important for functionality. I just want to avoid unnecessary clutter in my home directory while still sharing a few important directories with the firejailed application.

I like Vincent43s suggestion of a separate whitelist to not break existing functionality. In any case, not being able to share some directories between the personal home and the firejail home is limiting some functionality.

@3ThumbsUp commented on GitHub (Jan 13, 2022): I'd like to voice support for this feature. One of my use cases is that I use firejail with Steam. As Steam seems to clutter the home directory more than any other program, I've given it its own firejailed home. That way Steam can do whatever it wants to, and all the clutter is out of my way in a separate directory. However, this limits some of the features. For example, I would still like Steam to be able to create desktop shortcuts, but for this to work, it needs access to /usr/share/applications and /usr/share/icons in the real home directory. Ideally, I would like it to have a firejailed home for all directories except those. The same argument goes for some proprietary video editing software (Davinci Resolve in my case). I want to give it its own home directory to not clutter my personal home, but it obviously still needs access to my Video directory. And I can't just use regular whitelists without private mode, because the files it creates are still important for functionality. I just want to avoid unnecessary clutter in my home directory while still sharing a few important directories with the firejailed application. I like Vincent43s suggestion of a separate whitelist to not break existing functionality. In any case, not being able to share some directories between the personal home and the firejail home is limiting some functionality.

gitea-mirror commented

2026-05-05 07:36:59 -06:00

Author

Owner

@evren320 commented on GitHub (Dec 14, 2022):

I need this feature too.
A separate permanent home for the app, with some folders of the user home accessible.
As a workaround, mount --bind serves this purpose, but requires root password to run every time launching the app and raises some security concern.

@evren320 commented on GitHub (Dec 14, 2022): I need this feature too. A separate permanent home for the app, with some folders of the user home accessible. As a workaround, mount --bind serves this purpose, but requires root password to run every time launching the app and raises some security concern.

gitea-mirror commented

2026-05-05 07:37:00 -06:00

Author

Owner

@hvhaugwitz commented on GitHub (May 25, 2024):

An option like --private-whitelist has legit use cases (see comments above).

Please consider to reopen this bug/feature request.

@hvhaugwitz commented on GitHub (May 25, 2024): An option like `--private-whitelist` has legit use cases (see comments above). Please consider to reopen this bug/feature request.

gitea-mirror commented

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

Author

Owner

@pjhfggij commented on GitHub (Oct 28, 2024):

I think "--private-with-whitelisting=SOME_PATH" option to poke a hole in --private firejail process would be a good idea. Otherwise I had to manually patch all the whitelist "holes" introduced by upstream profiles to be able to introduce my own selected whitelisted folders, I've had to spend an hour just to replicate --private in librewolf.local profile and I'm not looking forward having to redo this for other programs. "--private-whitelist" could free users from such chores.

@pjhfggij commented on GitHub (Oct 28, 2024): I think `"--private-with-whitelisting=SOME_PATH"` option to poke a hole in --private firejail process would be a good idea. Otherwise I had to manually patch all the whitelist "holes" introduced by upstream profiles to be able to introduce my own selected whitelisted folders, I've had to spend an hour just to replicate --private in [librewolf.local profile](https://0x0.st/X0qm.txt ) and I'm not looking forward having to redo this for other programs. `"--private-whitelist"` could free users from such chores.

gitea-mirror commented

2026-05-05 07:37:02 -06:00

Author

Owner

@kolAflash commented on GitHub (Feb 4, 2025):

It took me quite some time to figure out how --noprofile, --privateand--whitelist=...interact. **Please add some documentation.** Either in the man-page. Or ideallyfirejailshould report an error if the user callsfirejail --private --whitelist=$HOME/something`.

It should be noted, that:

--noprofile disables --private
Without --noprofile the --profile=default.profile is enabled by default. default blacklists directories like /etc/ssh/ and markes files like ~/.bashrc read-only.
- currently read-only can only be overwritten from another profile, not with command line --read-write=...
- --noprofile removes read-only and blacklist entries for sensitive files / directories
--whitelist= automatically hides $HOME
--private a --whitelist=$HOME/something will be ignored

@kolAflash commented on GitHub (Feb 4, 2025): It took me quite some time to figure out how `--noprofile`, --private` and `--whitelist=...` interact. **Please add some documentation.** Either in the man-page. Or ideally `firejail` should report an error if the user calls `firejail --private --whitelist=$HOME/something`. It should be noted, that: - `--noprofile` disables `--private` - Without `--noprofile` the `--profile=default.profile` is enabled by default. `default` blacklists directories like `/etc/ssh/` and markes files like `~/.bashrc` read-only. - currently `read-only` can only be overwritten from another profile, [not with command line --read-write=...](https://github.com/netblue30/firejail/issues/6639) - `--noprofile` removes read-only and blacklist entries for sensitive files / directories - `--whitelist=` automatically hides `$HOME` - `--private` a `--whitelist=$HOME/something` will be ignored

gitea-mirror commented

2026-05-05 07:37:03 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 4, 2025):

it does not
this is already documented
- see response in #6639
- we could make the security implications clearer like "Do not use a security profile. UNSECURE! Only for testing or special use.". On the other hand default.profile isn't secure either.
is half-true and already documented
send a PR to document it

@rusty-snake commented on GitHub (Feb 4, 2025): - it does not - this is already documented - see response in #6639 - we could make the security implications clearer like "Do not use a security profile. UNSECURE! Only for testing or special use.". On the other hand `default.profile` isn't secure either. - is half-true and already documented - send a PR to document it

gitea-mirror commented

2026-05-05 07:37:04 -06:00

Author

Owner

@kolAflash commented on GitHub (Feb 5, 2025):

@rusty-snake

"--whitelist=" automatically hides "$HOME"

is half-true and already documented

Thanks! Can you post a link?

@kolAflash commented on GitHub (Feb 5, 2025): @rusty-snake >> "--whitelist=" automatically hides "$HOME" > * is half-true and already documented Thanks! Can you post a link?

gitea-mirror commented

2026-05-05 07:37:05 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 5, 2025):

manpage:

Whitelist directory or file. A temporary file system is
mounted on the top directory, and the whitelisted files are
mount-binded inside. Modifications to whitelisted files are
persistent, everything else is discarded when the sandbox
is closed. The top directory can be all directories in /
(except /proc and /sys), /sys/module, /run/user/$UID, $HOME
and all directories in /usr.

and https://github.com/netblue30/firejail/wiki/Creating-overrides

if you have ideas how this can be documented in a better way, send a PR.

@rusty-snake commented on GitHub (Feb 5, 2025): manpage: > Whitelist directory or file. A temporary file system is mounted on the top directory, and the whitelisted files are mount-binded inside. Modifications to whitelisted files are persistent, everything else is discarded when the sandbox is closed. The top directory can be all directories in / (except /proc and /sys), /sys/module, /run/user/$UID, $HOME and all directories in /usr. and https://github.com/netblue30/firejail/wiki/Creating-overrides if you have ideas how this can be documented in a better way, send a PR.

gitea-mirror commented

2026-05-05 07:37:06 -06:00

Author

Owner

@rusty-snake commented on GitHub (Feb 6, 2025):

#6622 had been merged

@rusty-snake commented on GitHub (Feb 6, 2025): #6622 had been merged

gitea-mirror referenced this issue

2026-05-05 10:09:26 -06:00

[PR #1182] [MERGED] tidy up #3870

Rows
Columns

[GH-ISSUE #1743] Can't combine --private with --whitelist #1182