[GH-ISSUE #1078] Issue whitelisting or noblacklisting home dir #733

Closed
opened 2026-05-05 06:32:37 -06:00 by gitea-mirror · 4 comments
Owner

Originally created by @azimut on GitHub (Jan 29, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1078

I can't find a way to make firejail work with my setup. I have different users with different home directories on ex: /tree/a/b/c/ /tree/a/c/d/ , etc.

So I want to blacklist access to /tree, but whitelist access to the user home directory. There is a way to do this with the current --blacklist --noblacklist or --whitelist options? I cannot seem to find the correct ones.

I can blacklist /tree no problem, but cannot just "whitelist" the home (~/) subdir.

$ firejail --version
firejail version 0.9.44.8

Compile time support:
        - AppArmor support is disabled
        - AppImage support is enabled
        - bind support is enabled
        - chroot support is enabled
        - file and directory whitelisting support is enabled
        - file transfer support is enabled
        - networking support is enabled
        - overlayfs support is enabled
        - private-home support is enabled
        - seccomp-bpf support is enabled
        - user namespace support is enabled
        - X11 sandboxing support is enabled
$ rpm -qa | grep fireja
firejail-0.9.44.8-1.x86_64
Originally created by @azimut on GitHub (Jan 29, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1078 I can't find a way to make firejail work with my setup. I have different users with different home directories on ex: /tree/a/b/c/ /tree/a/c/d/ , etc. So I want to blacklist access to /tree, but whitelist access to the user home directory. There is a way to do this with the current --blacklist --noblacklist or --whitelist options? I cannot seem to find the correct ones. I can blacklist /tree no problem, but cannot just "whitelist" the home (~/) subdir. ``` $ firejail --version firejail version 0.9.44.8 Compile time support: - AppArmor support is disabled - AppImage support is enabled - bind support is enabled - chroot support is enabled - file and directory whitelisting support is enabled - file transfer support is enabled - networking support is enabled - overlayfs support is enabled - private-home support is enabled - seccomp-bpf support is enabled - user namespace support is enabled - X11 sandboxing support is enabled $ rpm -qa | grep fireja firejail-0.9.44.8-1.x86_64 ```
gitea-mirror 2026-05-05 06:32:37 -06:00
Author
Owner

@netblue30 commented on GitHub (Jan 30, 2017):

Masking the user accounts is kind of tricky, because you need to know where the user accounts are located. In this moment we can handle only user accounts stored under /home. Maybe we can bring this kind of support in a future release, but for now is not supported.

<!-- gh-comment-id:276071572 --> @netblue30 commented on GitHub (Jan 30, 2017): Masking the user accounts is kind of tricky, because you need to know where the user accounts are located. In this moment we can handle only user accounts stored under /home. Maybe we can bring this kind of support in a future release, but for now is not supported.
Author
Owner

@azimut commented on GitHub (Feb 2, 2017):

If I could --bind as non-root (with firejail suid set) I should be able to work around this. For reference "bubblewrap" allows that. But there should be a good reason to disable it here I think. Other than that my other option could be use "--chroot" with a pre-baked environment. Any guidelines written about --chroot with firejail?

<!-- gh-comment-id:277065729 --> @azimut commented on GitHub (Feb 2, 2017): If I could --bind as non-root (with firejail suid set) I should be able to work around this. For reference "bubblewrap" allows that. But there should be a good reason to disable it here I think. Other than that my other option could be use "--chroot" with a pre-baked environment. Any guidelines written about --chroot with firejail?
Author
Owner

@netblue30 commented on GitHub (Feb 4, 2017):

Binding as nonroot is dangerous. For example, you can bind an new version of /etc directory with a known password in /etc/shadow.

<!-- gh-comment-id:277446865 --> @netblue30 commented on GitHub (Feb 4, 2017): Binding as nonroot is dangerous. For example, you can bind an new version of /etc directory with a known password in /etc/shadow.
Author
Owner

@azimut commented on GitHub (Mar 20, 2017):

FWIW, I ended up having some free time to resume this. My workaround was create symlinks under /home pointing to /data/a/dir/ and add the blacklist of /data on default.profile.

<!-- gh-comment-id:287903894 --> @azimut commented on GitHub (Mar 20, 2017): FWIW, I ended up having some free time to resume this. My workaround was create symlinks under /home pointing to /data/a/dir/ and add the blacklist of /data on default.profile.
Sign in to join this conversation.
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#733
No description provided.