Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

whitelist + private logic changed after #4229 #4285

Closed
rusty-snake opened this issue May 18, 2021 · 6 comments
Closed

whitelist + private logic changed after #4229 #4285

rusty-snake opened this issue May 18, 2021 · 6 comments

Comments

@rusty-snake
Copy link
Collaborator

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.

@smitsohu
Copy link
Collaborator

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
Copy link
Collaborator

smitsohu commented 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
Copy link
Collaborator

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

@rusty-snake
Copy link
Collaborator Author

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
Copy link
Collaborator Author

4909fa7#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).

@netblue30
Copy link
Owner

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.

a2b81da

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants