[GH-ISSUE #1440] What's the difference between --chroot= and --private= ?

gitea-mirror commented

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

Owner

Originally created by @taoeffect on GitHub (Aug 8, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1440

I tried searching for an answer before opening this issue but could not find a clear one.

Some newb questions I have are:

What is the difference in purpose between the two flags?
When would one want to use one over the other?
Is it OK to use both? If so, what kinds of circumstances might one want to do that, and if not, why not?

Thanks so much for any help with figuring this out!

Originally created by @taoeffect on GitHub (Aug 8, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1440 I tried searching for an answer before opening this issue but could not find a clear one. Some newb questions I have are: - What is the difference in purpose between the two flags? - When would one want to use one over the other? - Is it OK to use both? If so, what kinds of circumstances might one want to do that, and if not, why not? Thanks so much for any help with figuring this out!

gitea-mirror closed this issue

2026-05-05 07:14:23 -06:00

gitea-mirror commented

2026-05-05 07:14:25 -06:00

Author

Owner

@Ferroin commented on GitHub (Aug 8, 2017):

--chroot= changes the root directory for the jail to the specified directory (check the man page for the actual system call here or on your local system for more info on what exactly is done). This is quite literally the oldest type of sandboxing on UNIX systems, and ironically wasn't intended originally for that purpose (and by itself is insufficient for sandboxing). In the case of firejail, it mostly provides some limited degree of insurance that's only significant if the other protections fail. As far as usage goes, the general rule is that unless you know you need to use --chroot=, you don't need it. It provides no measurable extra security, and can make setting up a jail much more complicated.

--private= creates an ephemeral instance (temporary for the duration of the jail) of the specified directory inside the jail (the stuff in the jail can't see the contents of the real version of that directory, and things outside the jail can't read the private instance). It builds on the technology firejail is already using, and is intended for hiding files from things running in the jail (or providing a customized view of those files). This is actually used in a number of profiles to hide things like system configuration files, and is sometimes used for things like web browsers to create throw-away profiles that get deleted when the browser exits.

The only circumstances I can think of that actually need both involve using firejail for traditional whole-system containers (that is LXC/LXD or VServer style containers), and there are much better options for such a use case than firejail.

@Ferroin commented on GitHub (Aug 8, 2017): `--chroot=` changes the root directory for the jail to the specified directory (check the man page for the actual system call [here](https://linux.die.net/man/2/chroot) or on your local system for more info on what exactly is done). This is quite literally the oldest type of sandboxing on UNIX systems, and ironically wasn't intended originally for that purpose (and by itself is insufficient for sandboxing). In the case of firejail, it mostly provides some limited degree of insurance that's only significant if the other protections fail. As far as usage goes, the general rule is that unless you know you need to use `--chroot=`, you don't need it. It provides no measurable extra security, and can make setting up a jail much more complicated. `--private=` creates an ephemeral instance (temporary for the duration of the jail) of the specified directory inside the jail (the stuff in the jail can't see the contents of the real version of that directory, and things outside the jail can't read the private instance). It builds on the technology firejail is already using, and is intended for hiding files from things running in the jail (or providing a customized view of those files). This is actually used in a number of profiles to hide things like system configuration files, and is sometimes used for things like web browsers to create throw-away profiles that get deleted when the browser exits. The only circumstances I can think of that actually need both involve using firejail for traditional whole-system containers (that is LXC/LXD or VServer style containers), and there are much better options for such a use case than firejail.

gitea-mirror commented

2026-05-05 07:14:27 -06:00

Author

Owner

@reinerh commented on GitHub (Aug 8, 2017):

--chroot is for running programs in a different root directory. For example you could have a different Linux distribution installed in /srv/chroot/ubuntu. The program from inside this new filesystem hierarchy is then called and jailed, instead of the one of your main system.

--private is for hiding directories from jailed applications. Without arguments to --private, the home directories will be made "private", so they will be mostly empty for jailed applications. And any changes to those directories will be discarded when the jail is ended.

Yes, you can combine both, as they are two completely separate functionalities.

@reinerh commented on GitHub (Aug 8, 2017): --chroot is for running programs in a different root directory. For example you could have a different Linux distribution installed in /srv/chroot/ubuntu. The program from inside this new filesystem hierarchy is then called and jailed, instead of the one of your main system. --private is for hiding directories from jailed applications. Without arguments to --private, the home directories will be made "private", so they will be mostly empty for jailed applications. And any changes to those directories will be discarded when the jail is ended. Yes, you can combine both, as they are two completely separate functionalities.

gitea-mirror commented

2026-05-05 07:14:28 -06:00

Author

Owner

@taoeffect commented on GitHub (Aug 8, 2017):

Thanks guys! That's super helpful!

One last question (and maybe consider linking to these answers from the website docs? I bet I'm not the only person that would find them enlightening!):

Yes, you can combine both, as they are two completely separate functionalities.

This is the part that confuses me, as isn't the home folder within root? So if you change the root, doesn't that by itself change the home directory, rendering --private meaningless...?

@taoeffect commented on GitHub (Aug 8, 2017): Thanks guys! That's super helpful! One last question (and maybe consider linking to these answers from the website docs? I bet I'm not the only person that would find them enlightening!): > Yes, you can combine both, as they are two completely separate functionalities. This is the part that confuses me, as isn't the home folder within root? So if you change the root, doesn't that by itself change the home directory, rendering `--private` meaningless...?

gitea-mirror commented

2026-05-05 07:14:31 -06:00

Author

Owner

@reinerh commented on GitHub (Aug 8, 2017):

What you change in the chroot directory is persistent. So even though you have a different home directory, it is not a temporary one (just a different one).
--private gives your application a private/temporary home directory, but the rest of your system stays the same (i.e., same Linux distribution, same installed applications etc.).
With --chroot you run the application in a completely different Linux "environment" (it doesn't need to be the same distribution), for example with different versions of your applications, different configurations etc. Another common use case for chroots is having one for different architecture binaries, for example you have a 64bit host system, but a separate 32bit system in a chroot directory.

@reinerh commented on GitHub (Aug 8, 2017): What you change in the chroot directory is persistent. So even though you have a different home directory, it is not a temporary one (just a different one). --private gives your application a private/temporary home directory, but the rest of your system stays the same (i.e., same Linux distribution, same installed applications etc.). With --chroot you run the application in a completely different Linux "environment" (it doesn't need to be the same distribution), for example with different versions of your applications, different configurations etc. Another common use case for chroots is having one for different architecture binaries, for example you have a 64bit host system, but a separate 32bit system in a chroot directory.

gitea-mirror commented

2026-05-05 07:14:33 -06:00

Author

Owner

@taoeffect commented on GitHub (Aug 8, 2017):

Thanks so much @reinerh!

So it sounds like if you use --chroot=[dir] with --private=[dir] then it will both change the root and also replace the home directory in the new root with a persistent home directory outside of it. (Please correct me if that understanding is mistaken!)

I'm going to close this issue now since my question has been answered, I think, quite well.

If you'd like to update the website with a link to this issue to help others understand the differences that would be grand.

Cheers and have a wonderful day!

@taoeffect commented on GitHub (Aug 8, 2017): Thanks so much @reinerh! So it sounds like if you use `--chroot=[dir]` with `--private=[dir]` then it will *both* change the root and also replace the home directory in the new root with a persistent home directory outside of it. (Please correct me if that understanding is mistaken!) I'm going to close this issue now since my question has been answered, I think, quite well. If you'd like to update the website with a link to this issue to help others understand the differences that would be grand. Cheers and have a wonderful day!

gitea-mirror commented

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

Author

Owner

@reinerh commented on GitHub (Aug 8, 2017):

it sounds like if you use --chroot=[dir] with --private=[dir] then it will both change the root and also replace the home directory in the new root with a persistent home directory outside of it.

Not quite. --chroot will change the root directory, and --private will use a temporary/non-persistent home directory.
If you use --chroot=/srv/chroot/ubuntu without --private, then your newly created files will stay in e.g. /srv/chroot/ubuntu/home/username/foo.txt, with --private they will get lost.

Here is an example that shows you the behavior:

(reiner@apollo) ~ $ > ls -l /srv/chroot/jessie/home/reiner/
total 0
(reiner@apollo) ~ $ > firejail --quiet --chroot=/srv/chroot/jessie
(jessie)reiner@apollo:~$ touch foo
(jessie)reiner@apollo:~$ exit
(reiner@apollo) ~ $ > ls -l /srv/chroot/jessie/home/reiner/
total 0
-rw-r--r-- 1 reiner reiner 0 Aug  9 01:29 foo
(reiner@apollo) ~ $ > firejail --quiet --chroot=/srv/chroot/jessie --private
(jessie)reiner@apollo:~$ ls -l
total 0
(jessie)reiner@apollo:~$ touch bar
(jessie)reiner@apollo:~$ exit
(reiner@apollo) ~ $ > ls -l /srv/chroot/jessie/home/reiner/
total 0
-rw-r--r-- 1 reiner reiner 0 Aug  9 01:29 foo
(reiner@apollo) ~ $ >

@reinerh commented on GitHub (Aug 8, 2017): > it sounds like if you use --chroot=[dir] with --private=[dir] then it will both change the root and also replace the home directory in the new root with a persistent home directory outside of it. Not quite. --chroot will change the root directory, and --private will use a temporary/non-persistent home directory. If you use `--chroot=/srv/chroot/ubuntu` without --private, then your newly created files will stay in e.g. /srv/chroot/ubuntu/home/username/foo.txt, with --private they will get lost. Here is an example that shows you the behavior: ``` (reiner@apollo) ~ $ > ls -l /srv/chroot/jessie/home/reiner/ total 0 (reiner@apollo) ~ $ > firejail --quiet --chroot=/srv/chroot/jessie (jessie)reiner@apollo:~$ touch foo (jessie)reiner@apollo:~$ exit (reiner@apollo) ~ $ > ls -l /srv/chroot/jessie/home/reiner/ total 0 -rw-r--r-- 1 reiner reiner 0 Aug 9 01:29 foo (reiner@apollo) ~ $ > firejail --quiet --chroot=/srv/chroot/jessie --private (jessie)reiner@apollo:~$ ls -l total 0 (jessie)reiner@apollo:~$ touch bar (jessie)reiner@apollo:~$ exit (reiner@apollo) ~ $ > ls -l /srv/chroot/jessie/home/reiner/ total 0 -rw-r--r-- 1 reiner reiner 0 Aug 9 01:29 foo (reiner@apollo) ~ $ > ```

gitea-mirror commented

2026-05-05 07:14:35 -06:00

Author

Owner

@taoeffect commented on GitHub (Aug 8, 2017):

Not quite. --chroot will change the root directory, and --private will use a temporary/non-persistent home directory.

That's not what the documentation says? That only happens when --private is used without any parameters?

@taoeffect commented on GitHub (Aug 8, 2017): > Not quite. --chroot will change the root directory, and --private will use a temporary/non-persistent home directory. That's not what the documentation says? That only happens when `--private` is used without any parameters?

gitea-mirror commented

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

Author

Owner

@reinerh commented on GitHub (Aug 8, 2017):

Oh sorry, I didn't see in your other reply that you mean --private=directory (instead of --private).
In that case you are absolutely right, the specified directory will be used and the files are persisted in there.

@reinerh commented on GitHub (Aug 8, 2017): Oh sorry, I didn't see in your other reply that you mean --private=directory (instead of --private). In that case you are absolutely right, the specified directory will be used and the files are persisted in there.

gitea-mirror commented

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

Author

Owner

@Ferroin commented on GitHub (Aug 9, 2017):

That said, I don't think it documents anywhere what order those are evaluated in. There's a pretty big difference between evaluating the --private= option before versus after the chroot happens.

@Ferroin commented on GitHub (Aug 9, 2017): That said, I don't think it documents anywhere what order those are evaluated in. There's a pretty big difference between evaluating the `--private=` option before versus after the chroot happens.

gitea-mirror commented

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

Author

Owner

@Raj2032 commented on GitHub (Mar 25, 2019):

--chroot= changes the root directory for the jail to the specified directory (check the man page for the actual system call here or on your local system for more info on what exactly is done). This is quite literally the oldest type of sandboxing on UNIX systems, and ironically wasn't intended originally for that purpose (and by itself is insufficient for sandboxing). In the case of firejail, it mostly provides some limited degree of insurance that's only significant if the other protections fail. As far as usage goes, the general rule is that unless you know you need to use --chroot=, you don't need it. It provides no measurable extra security, and can make setting up a jail much more complicated.

--private= creates an ephemeral instance (temporary for the duration of the jail) of the specified directory inside the jail (the stuff in the jail can't see the contents of the real version of that directory, and things outside the jail can't read the private instance). It builds on the technology firejail is already using, and is intended for hiding files from things running in the jail (or providing a customized view of those files). This is actually used in a number of profiles to hide things like system configuration files, and is sometimes used for things like web browsers to create throw-away profiles that get deleted when the browser exits.

The only circumstances I can think of that actually need both involve using firejail for traditional whole-system containers (that is LXC/LXD or VServer style containers), and there are much better options for such a use case than firejail.

Using --private= can I create another directory and install programs in that specific folder?

@Raj2032 commented on GitHub (Mar 25, 2019): > `--chroot=` changes the root directory for the jail to the specified directory (check the man page for the actual system call [here](https://linux.die.net/man/2/chroot) or on your local system for more info on what exactly is done). This is quite literally the oldest type of sandboxing on UNIX systems, and ironically wasn't intended originally for that purpose (and by itself is insufficient for sandboxing). In the case of firejail, it mostly provides some limited degree of insurance that's only significant if the other protections fail. As far as usage goes, the general rule is that unless you know you need to use `--chroot=`, you don't need it. It provides no measurable extra security, and can make setting up a jail much more complicated. > > `--private=` creates an ephemeral instance (temporary for the duration of the jail) of the specified directory inside the jail (the stuff in the jail can't see the contents of the real version of that directory, and things outside the jail can't read the private instance). It builds on the technology firejail is already using, and is intended for hiding files from things running in the jail (or providing a customized view of those files). This is actually used in a number of profiles to hide things like system configuration files, and is sometimes used for things like web browsers to create throw-away profiles that get deleted when the browser exits. > > The only circumstances I can think of that actually need both involve using firejail for traditional whole-system containers (that is LXC/LXD or VServer style containers), and there are much better options for such a use case than firejail. Using `--private=` can I create another directory and install programs in that specific folder?

Rows
Columns

[GH-ISSUE #1440] What's the difference between --chroot= and --private= ? #971