github-starred/firejail

Fork 0

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

[GH-ISSUE #4285] whitelist + private logic changed after #4229 #2606

New issue

Closed

opened 2026-05-05 09:16:30 -06:00 by gitea-mirror · 6 comments

gitea-mirror commented

2026-05-05 09:16:30 -06:00

Owner

Originally created by @rusty-snake on GitHub (May 18, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4285

File-system layout:

$ ls ~/foo
bar
baz

Before #4229 firejail --shell=none --whitelist=~/baz --private=~/foo ~/bar had executed ~/foo/bar with ~/foo as private $HOME and the --whitelist=~/baz was ignored (meaning whitelisting wasn't enabled).

After #4229 you need to add --whitelist=~/bar. Otherwise you get Error: no suitable ~/bar executable found.

That's what I found out so far. I'm not 100% sure if this are the right STR. I'm also not sure if this behaviour is maybe better then the old, as it seems whitelist was ignored previously.

Originally created by @rusty-snake on GitHub (May 18, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4285 File-system layout: ``` $ ls ~/foo bar baz ``` Before #4229 `firejail --shell=none --whitelist=~/baz --private=~/foo ~/bar` had executed `~/foo/bar` with `~/foo` as private $HOME and the `--whitelist=~/baz` was ignored (meaning whitelisting wasn't enabled). After #4229 you need to add `--whitelist=~/bar`. Otherwise you get `Error: no suitable ~/bar executable found`. That's what I found out so far. I'm not 100% sure if this are the right STR. I'm also not sure if this behaviour is maybe better then the old, as it seems `whitelist` was ignored previously.

gitea-mirror closed this issue

2026-05-05 09:16:31 -06:00

gitea-mirror commented

2026-05-05 09:16:33 -06:00

Author

Owner

@smitsohu commented on GitHub (May 18, 2021):

I thought nobody would notice 😄

It was a conscious decision to keep things a bit more simple, but of course the old behaviour can be added back.

@smitsohu commented on GitHub (May 18, 2021): I thought nobody would notice :smile: It was a conscious decision to keep things a bit more simple, but of course the old behaviour can be added back.

gitea-mirror commented

2026-05-05 09:16:34 -06:00

Author

Owner

@smitsohu commented on GitHub (May 18, 2021):

IIRC another reason why I did it like this is because it avoids creating a special case for the user home directory. All other private options can be combined freely with whitelist, also before #4229. It seemed advantageous to me to keep it like that because it enabled a workaround for missing subdirectory support in private-etc (now implemented), private-home, and so on.

That said, private and private= do something different than the other private options, and combining them with whitelist doesn't really make much sense.

@smitsohu commented on GitHub (May 18, 2021): IIRC another reason why I did it like this is because it avoids creating a special case for the user home directory. All other private options can be combined freely with whitelist, also before #4229. It seemed advantageous to me to keep it like that because it enabled a workaround for missing subdirectory support in `private-etc` (now implemented), `private-home`, and so on. That said, `private` and `private=` do something different than the other private options, and combining them with whitelist doesn't really make much sense.

gitea-mirror commented

2026-05-05 09:16:35 -06:00

Author

Owner

@smitsohu commented on GitHub (May 19, 2021):

@rusty-snake Nevermind, I'll add it back so it behaves as before.

@smitsohu commented on GitHub (May 19, 2021): @rusty-snake Nevermind, I'll add it back so it behaves as before.

gitea-mirror commented

2026-05-05 09:16:36 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 19, 2021):

I create this issues because I'm wasn't sure if this was intentionally or a mistake. Maybe it's better to have whitelist working in --private=shared_private_home. Some complex setups maybe need to be adjusted, however users with such setups can do this IMHO if we add it to the RELONTES:

@rusty-snake commented on GitHub (May 19, 2021): I create this issues because I'm wasn't sure if this was intentionally or a mistake. Maybe it's better to have `whitelist` working in `--private=shared_private_home`. Some complex setups maybe need to be adjusted, however users with such setups can do this IMHO if we add it to the RELONTES:

gitea-mirror commented

2026-05-05 09:16:38 -06:00

Author

Owner

@rusty-snake commented on GitHub (May 26, 2021):

4909fa7efc (diff-6698244f9a67e5c8ae5c03806df74f6d9f1ae1b31ad6176eb09e136f07f3dad9) whitelists all files in $HOME by default (you can ignore this profile_add IIRC). This still means that a program can not save files (e.g. documents/pictures or configs/caches) in files/dirs that don't exists when the sandbox is started (and mkdir still don't work with private).

@rusty-snake commented on GitHub (May 26, 2021): https://github.com/netblue30/firejail/commit/4909fa7efce4a36bd16e7bf80c9642b93c262ddf#diff-6698244f9a67e5c8ae5c03806df74f6d9f1ae1b31ad6176eb09e136f07f3dad9 `whitelist`s all files in $HOME by default (you can `ignore` this `profile_add` IIRC). This still means that a program can not save files (e.g. documents/pictures or configs/caches) in files/dirs that don't exists when the sandbox is started (and `mkdir` still don't work with `private`).

gitea-mirror commented

2026-05-05 09:16:39 -06:00

Author

Owner

@netblue30 commented on GitHub (May 29, 2021):

4909fa7

I was looking for a quick and dirty fix for tor browser, and somehow it got checked in with something else. I took it out, and put the disable whitelist functionality back.

a2b81da0f3

@netblue30 commented on GitHub (May 29, 2021): > 4909fa7 I was looking for a quick and dirty fix for tor browser, and somehow it got checked in with something else. I took it out, and put the disable whitelist functionality back. https://github.com/netblue30/firejail/commit/a2b81da0f38fc34c9587a1fdc0709ef6fe6ca13d

gitea-mirror referenced this issue

2026-05-05 10:20:14 -06:00

[PR #2606] [MERGED] Harden easystroke #4443

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

No description provided.

Rows
Columns