[GH-ISSUE #459] Patch to bind user home directories

gitea-mirror commented

2026-05-05 05:36:18 -06:00

Owner

Originally created by @lepasserby on GitHub (Apr 19, 2016).
Original GitHub issue: https://github.com/netblue30/firejail/issues/459

Hi!
Perhaps a silly question, but it was mentioned that --x11 is not available for root.

Would it work for cases where firejail is called like

sudo firejail --x11 --user=non-root-user --net=br1 program-name
?

Reason for sudoing: need to bind a "host" directory into the sandbox at startup (so the jailed program's output is available to certain processes at host), thus plan to have whitelist directory directive in the profile and it requires root.

program that needs to be jailed can run as non-root (hence --user=non-root-user)

Originally created by @lepasserby on GitHub (Apr 19, 2016). Original GitHub issue: https://github.com/netblue30/firejail/issues/459 Hi! Perhaps a silly question, but it was mentioned that --x11 is not available for root. Would it work for cases where firejail is called like _sudo firejail --x11 --user=non-root-user --net=br1 program-name_ ? Reason for sudoing: need to bind a "host" directory into the sandbox at startup (so the jailed program's output is available to certain processes at host), thus plan to have whitelist directory directive in the profile and it requires root. program that needs to be jailed can run as non-root (hence --user=non-root-user)

gitea-mirror added the

enhancement

label 2026-05-05 05:36:18 -06:00

gitea-mirror commented

2026-05-05 05:36:21 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 20, 2016):

The order Firejail applies the commands will prevent you from doing it. This is something that will work:

Start with a naked root sandbox where you apply the bind:

$ sudo firejail --noprofile --bind=t1,t2

Switch to your user:

# sudo netblue

Start the real x11 sandbox using --force:

$ firejail --force --x11 --net=eth0 xterm

Or you can do all in one line:

$ sudo firejail --noprofile --bind=t1,t2 sudo -u netblue firejail --force --net=eth0 --x11 xterm

@netblue30 commented on GitHub (Apr 20, 2016): The order Firejail applies the commands will prevent you from doing it. This is something that will work: Start with a naked root sandbox where you apply the bind: ``` $ sudo firejail --noprofile --bind=t1,t2 ``` Switch to your user: ``` # sudo netblue ``` Start the real x11 sandbox using --force: ``` $ firejail --force --x11 --net=eth0 xterm ``` Or you can do all in one line: ``` $ sudo firejail --noprofile --bind=t1,t2 sudo -u netblue firejail --force --net=eth0 --x11 xterm ```

gitea-mirror commented

2026-05-05 05:36:23 -06:00

Author

Owner

@lepasserby commented on GitHub (Apr 20, 2016):

I assume if I want to apply secomp filters or something like that, I'd best do that in the "last" firejail (the --force one) ?

Should first firejail come with --noprofile, or could it have one?

If "naked" firejail is started with a specific profile, would the second (--force) one honor the profile (esp whitelist directive) ?

@lepasserby commented on GitHub (Apr 20, 2016): I assume if I want to apply secomp filters or something like that, I'd best do that in the "last" firejail (the --force one) ? Should first firejail come with --noprofile, or could it have one? If "naked" firejail is started with a specific profile, would the second (--force) one honor the profile (esp whitelist directive) ?

gitea-mirror commented

2026-05-05 05:36:25 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 20, 2016):

Yes, seccomp is applied to the second sandbox. If you put it in the first sandbox, the second one will not start.

And yes, you can use also use a profile for the first sandbox, but don't put in anything that might prevent the second sandbox from starting, such as seccomp, caps etc. Whitelisting should work in the first profile.

@netblue30 commented on GitHub (Apr 20, 2016): Yes, seccomp is applied to the second sandbox. If you put it in the first sandbox, the second one will not start. And yes, you can use also use a profile for the first sandbox, but don't put in anything that might prevent the second sandbox from starting, such as seccomp, caps etc. Whitelisting should work in the first profile.

gitea-mirror commented

2026-05-05 05:36:26 -06:00

Author

Owner

@lepasserby commented on GitHub (Apr 20, 2016):

Okay, thanks!

Last (maybe) question (tangentially related, but might deserve own issue)

Let's say I want to run program in a "hollow" non-persistent homedir (as achieved by --private) but want to make one specific directory in the new homedir available to host and/or persistent.

What profile and command line directives and in what order would achieve that ?

@lepasserby commented on GitHub (Apr 20, 2016): Okay, thanks! Last (maybe) question (tangentially related, but might deserve own issue) Let's say I want to run program in a "hollow" non-persistent homedir (as achieved by --private) but want to make one specific directory in the new homedir available to host and/or persistent. What profile and command line directives and in what order would achieve that ?

gitea-mirror commented

2026-05-05 05:36:28 -06:00

Author

Owner

@netblue30 commented on GitHub (Apr 21, 2016):

You would use --whitelist. Example:

$ firejail --whitelist=~/somedir

will create a "hollow" /home/user directory with /home/user/somedir imported form the filesystem and it will be persistent.

@netblue30 commented on GitHub (Apr 21, 2016): You would use --whitelist. Example: ``` $ firejail --whitelist=~/somedir ``` will create a "hollow" /home/user directory with /home/user/somedir imported form the filesystem and it will be persistent.

gitea-mirror commented

2026-05-05 05:36:29 -06:00

Author

Owner

@djfd commented on GitHub (Dec 13, 2016):

just a couple of cents,

there is a patch allowing to mount a few home subdirectories in bind mode, thus their content is fully synchronized between a host and sandbox.

I do not know how secure it is, is it possible to escape somehow using such kind of binding or not...
Experts advises and thoughts related to this approach are very welcome!

binding-home-subdir.patch.txt

@djfd commented on GitHub (Dec 13, 2016): just a couple of cents, there is a patch allowing to mount a few home subdirectories in bind mode, thus their content is fully synchronized between a host and sandbox. I do not know how secure it is, is it possible to escape somehow using such kind of binding or not... Experts advises and thoughts related to this approach are very welcome! [binding-home-subdir.patch.txt](https://github.com/netblue30/firejail/files/648035/binding-home-subdir.patch.txt)

gitea-mirror commented

2026-05-05 05:36:31 -06:00

Author

Owner

@netblue30 commented on GitHub (Dec 13, 2016):

Thanks, I'll look into it.

@netblue30 commented on GitHub (Dec 13, 2016): Thanks, I'll look into it.

gitea-mirror commented

2026-05-05 05:36:32 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (Jul 15, 2018):

Isn't --force deprecated now? So how would one do this with the newer firejail versions?

@chiraag-nataraj commented on GitHub (Jul 15, 2018): Isn't `--force` deprecated now? So how would one do this with the newer `firejail` versions?

gitea-mirror commented

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

Author

Owner

@tonsimple commented on GitHub (Sep 12, 2018):

@netblue30 @chiraag-nataraj

I too have an interest in launching firejailed apps from a limited user, but in a firejail environment that was initially set up using "root-stuff"

"--force" still works for me (version 0.9.44.8 Debian 8) but if it is "on its way out" that may cause issues for me later on so I would like to know what's best practice is for the kind of thing I'm doing

P.S.:
Also, I would like to humbly request the return of --user command line switch. I realize there are probably practical reasons for its removal, but it was so comfy

@tonsimple commented on GitHub (Sep 12, 2018): @netblue30 @chiraag-nataraj I too have an interest in launching firejailed apps from a limited user, but in a firejail environment that was initially set up using "root-stuff" "--force" still works for me (version 0.9.44.8 Debian 8) but if it is "on its way out" that may cause issues for me later on so I would like to know what's best practice is for the kind of thing I'm doing P.S.: Also, I would like to humbly request the return of --user command line switch. I realize there are probably practical reasons for its removal, but it was so comfy

gitea-mirror commented

2026-05-05 05:36:36 -06:00

Author

Owner

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

It was removed due to security concerns so I doubt it will be ever restored.

@Vincent43 commented on GitHub (Sep 12, 2018): It was removed due to security concerns so I doubt it will be ever restored.

gitea-mirror commented

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

Author

Owner

@tonsimple commented on GitHub (Sep 22, 2018):

@Vincent43
Woah, that sounds bad.

@netblue30 , is running firejail "as someone else" unsafe in principle, or is it just --user implementation that was not very safe?

I'm currently doing

run firejail as root, set up environment, then use daemonize binary (easy to build on most platforms) to run another firejail with --force and proper profile (including seccomp and capability filters) . Seems to be working fine and daemonize offers a few neat bells and whistles.

using su to launch second firejail also works, I just kind of like daemonize more.

Is such a methodology somehow bad?

@tonsimple commented on GitHub (Sep 22, 2018): @Vincent43 Woah, that sounds bad. @netblue30 , is running firejail "as someone else" unsafe in principle, or is it just --user implementation that was not very safe? I'm currently doing run firejail as root, set up environment, then use daemonize binary (easy to build on most platforms) to run another firejail with --force and proper profile (including seccomp and capability filters) . Seems to be working fine and daemonize offers a few neat bells and whistles. using su to launch second firejail also works, I just kind of like daemonize more. Is such a methodology somehow bad?

gitea-mirror commented

2026-05-05 05:36:39 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jan 25, 2020):

Something like --bind-home=s,t would allow a lot of workarounds, I'm thinking #3139, …

@rusty-snake commented on GitHub (Jan 25, 2020): Something like `--bind-home=s,t` would allow a lot of workarounds, I'm thinking #3139, …

Rows
Columns

[GH-ISSUE #459] Patch to bind user home directories #325