[GH-ISSUE #4026] --private and $HOME

gitea-mirror commented

2026-05-05 09:11:28 -06:00

Owner

Originally created by @reinerh on GitHub (Mar 2, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4026

A Debian user reported the oddity that a bin directory inside a --private home directory is read-only.
This is caused by read-only ${HOME}/bin from disable-common.inc.

Is it actually intended that ${HOME} applies to the private home directory as well?

Originally created by @reinerh on GitHub (Mar 2, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4026 A Debian user [reported](https://bugs.debian.org/983746) the oddity that a `bin` directory inside a `--private` home directory is read-only. This is caused by `read-only ${HOME}/bin` from `disable-common.inc`. Is it actually intended that `${HOME}` applies to the private home directory as well?

gitea-mirror

2026-05-05 09:11:28 -06:00

closed this issue
added the
question_old
label

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Mar 2, 2021):

If not we can close #903.

I would have thought that the typical use is to create a directory,
copy a minimum number of (non-confidential) files in it, and do
all the dirty work in it via "firejail --private=". I do that for
testing actively developed 3rd party software, and this needs
something like "make install" each time the software is updated.
If bin is read-only, this doesn't work.

That's one workflow, another can be --private=~/work or --private=~/kleingartenverein. Then ${HOME} should expand to the --private home. Let's say you run ssh and firefox in ~/work, then you don't want that firefox can read the ssh keys of your company.

So I think it's better to expand ${HOME} to --private and use noblacklist/nowhitelist/read-write/ignore.

@rusty-snake commented on GitHub (Mar 2, 2021): If not we can close #903. ------ > I would have thought that the typical use is to create a directory, copy a minimum number of (non-confidential) files in it, and do all the dirty work in it via "firejail --private=". I do that for testing actively developed 3rd party software, and this needs something like "make install" each time the software is updated. If bin is read-only, this doesn't work. That's one workflow, another can be `--private=~/work` or `--private=~/kleingartenverein`. Then ${HOME} should expand to the --private home. Let's say you run ssh and firefox in ~/work, then you don't want that firefox can read the ssh keys of your company. So I think it's better to expand ${HOME} to --private and use noblacklist/nowhitelist/read-write/ignore.

gitea-mirror commented

2026-05-05 09:11:32 -06:00

Author

Owner

@vinc17fr commented on GitHub (Mar 2, 2021):

Well, if firefox cannot read the ssh configuration, then ssh won't be able to read it either (both being run in the jail)! So what's the point of storing ssh configuration in ~/work?

@vinc17fr commented on GitHub (Mar 2, 2021): Well, if firefox cannot read the ssh configuration, then ssh won't be able to read it either (both being run in the jail)! So what's the point of storing ssh configuration in `~/work`?

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Mar 2, 2021):

Well, if firefox cannot read the ssh configuration, then ssh won't be able to read it either (both being run in the jail)!

The workflow would look like firejail --private=~/work firefox and firejail --private=~/work ssh. Both will use their own profile (with may has noblacklist ${HOME}/.ssh).

So what's the point of storing ssh configuration in ~/work?

Using different homes for work, personal stuff, association activity, ... (https://firejail.wordpress.com/documentation-2/firefox-guide/#work).

@rusty-snake commented on GitHub (Mar 2, 2021): > Well, if firefox cannot read the ssh configuration, then ssh won't be able to read it either (both being run in the jail)! The workflow would look like `firejail --private=~/work firefox` and `firejail --private=~/work ssh`. Both will use their own profile (with may has `noblacklist ${HOME}/.ssh`). > So what's the point of storing ssh configuration in ~/work? Using different homes for work, personal stuff, association activity, ... (https://firejail.wordpress.com/documentation-2/firefox-guide/#work).

gitea-mirror commented

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

Author

Owner

@reinerh commented on GitHub (Mar 2, 2021):

@vinc17fr Would it work for you to create overrides in disable-common.local (or your own profile if you are using one)?
Some users might already be relying on the fact that $HOME also applies to private home directories, so it's difficult to loosen this now.

@reinerh commented on GitHub (Mar 2, 2021): @vinc17fr Would it work for you to create overrides in `disable-common.local` (or your own profile if you are using one)? Some users might already be relying on the fact that `$HOME` also applies to private home directories, so it's difficult to loosen this now.

gitea-mirror commented

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

Author

Owner

@vinc17fr commented on GitHub (Mar 2, 2021):

If firefox and ssh have their own profile, I suppose that it is this profile that should blacklist/restrict the various files and directories, just like if --private were not used. Having to use things like noblacklist ${HOME}/.ssh for ssh would just be ugly and error prone.

What do you mean by overrides? Note that just unblacklisting bin would not be sufficient in general. There should be no restriction on files inside the private directory.

@vinc17fr commented on GitHub (Mar 2, 2021): If firefox and ssh have their own profile, I suppose that it is this profile that should blacklist/restrict the various files and directories, just like if `--private` were not used. Having to use things like `noblacklist ${HOME}/.ssh` for ssh would just be ugly and error prone. What do you mean by overrides? Note that just unblacklisting `bin` would not be sufficient in general. There should be no restriction on files inside the private directory.

gitea-mirror commented

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

Author

Owner

@reinerh commented on GitHub (Mar 2, 2021):

If firefox and ssh have their own profile, I suppose that it is this profile that should blacklist/restrict the various files and directories

Disallowing acces to e.g. ${HOME}/.ssh makes sense globally. It is too much maintenance effort to blacklist common sensitive paths in every single profile.

Having to use things like noblacklist ${HOME}/.ssh for ssh would just be ugly and error prone

This is currently the case for the ssh.profile. Exactly this "pattern" allows blacklisting .ssh globally by default. Having to remember to put it into every profile is more error prone.

What do you mean by overrides? Note that just unblacklisting bin would not be sufficient in general.

I mean adding ignore read-only ${HOME}/bin to disable-common.local (or the profile of your application you use with a private home). This will prevent having read-only bin directory.

There should be no restriction on files inside the private directory.

I think your use case is different than others. If you really want no restriction at all, you could also use --noprofile to not load any profile (firejail --noprofile --private=fj-test).

@reinerh commented on GitHub (Mar 2, 2021): > If firefox and ssh have their own profile, I suppose that it is this profile that should blacklist/restrict the various files and directories Disallowing acces to e.g. `${HOME}/.ssh` makes sense globally. It is too much maintenance effort to blacklist common sensitive paths in every single profile. > Having to use things like noblacklist ${HOME}/.ssh for ssh would just be ugly and error prone This is currently the case for the `ssh.profile`. Exactly this "pattern" allows blacklisting .ssh globally by default. Having to remember to put it into every profile is more error prone. > What do you mean by overrides? Note that just unblacklisting bin would not be sufficient in general. I mean adding `ignore read-only ${HOME}/bin` to `disable-common.local` (or the profile of your application you use with a private home). This will prevent having read-only bin directory. > There should be no restriction on files inside the private directory. I think your use case is different than others. If you really want no restriction at all, you could also use `--noprofile` to not load any profile (`firejail --noprofile --private=fj-test`).

gitea-mirror commented

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

Author

Owner

@vinc17fr commented on GitHub (Mar 2, 2021):

Having to use things like noblacklist ${HOME}/.ssh for ssh would just be ugly and error prone

This is currently the case for the ssh.profile.

But the ssh.profile is fine. I'm talking about the default profile.

There should be no restriction on files inside the private directory.

I think your use case is different than others. If you really want no restriction at all, you could also use --noprofile to not load any profile (firejail --noprofile --private=fj-test).

This is not OK. I still want the usual blacklists, e.g. /etc/ssh.

@vinc17fr commented on GitHub (Mar 2, 2021): > > Having to use things like noblacklist ${HOME}/.ssh for ssh would just be ugly and error prone > > This is currently the case for the `ssh.profile`. But the `ssh.profile` is fine. I'm talking about the default profile. > > There should be no restriction on files inside the private directory. > > I think your use case is different than others. If you really want no restriction at all, you could also use `--noprofile` to not load any profile (`firejail --noprofile --private=fj-test`). This is not OK. I still want the usual blacklists, e.g. `/etc/ssh`.

gitea-mirror commented

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

Author

Owner

@reinerh commented on GitHub (Mar 2, 2021):

Can you please explain why modifying your application's profile (or .local override file) is not an option for you?

Unfortunately no profile works for 100% of users, and .local files are there to allow customizations for some corner cases.

@reinerh commented on GitHub (Mar 2, 2021): Can you please explain why modifying your application's profile (or .local override file) is not an option for you? Unfortunately no profile works for 100% of users, and .local files are there to allow customizations for some corner cases.

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Mar 2, 2021):

This is not OK. I still want the usual blacklists, e.g. /etc/ssh.

$ cp /usr/share/doc/firejail/profile.template ~/.config/firejail/my_devel_activity_in_private.profile
# or
$ cp /etc/firejail/default.profile ~/.config/firejail/my_devel_activity_in_private.profile
$ vim ~/.config/firejail/my_devel_activity_in_private.profile
# customize as you need
$ firejail --private=~/foo --profile=my_devel_activity_in_private bash

@rusty-snake commented on GitHub (Mar 2, 2021): > This is not OK. I still want the usual blacklists, e.g. /etc/ssh. ``` $ cp /usr/share/doc/firejail/profile.template ~/.config/firejail/my_devel_activity_in_private.profile # or $ cp /etc/firejail/default.profile ~/.config/firejail/my_devel_activity_in_private.profile $ vim ~/.config/firejail/my_devel_activity_in_private.profile # customize as you need $ firejail --private=~/foo --profile=my_devel_activity_in_private bash ```

gitea-mirror commented

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

Author

Owner

@vinc17fr commented on GitHub (Mar 2, 2021):

Can you please explain why modifying your application's profile (or .local override file) is not an option for you?

How can one ignore all the read-only?

Something like ignore read-only ${HOME}/* does not work.

@vinc17fr commented on GitHub (Mar 2, 2021): > Can you please explain why modifying your application's profile (or .local override file) is not an option for you? How can one ignore all the `read-only`? Something like `ignore read-only ${HOME}/*` does not work.

gitea-mirror commented

2026-05-05 09:11:37 -06:00

Author

Owner

@rusty-snake commented on GitHub (Mar 2, 2021):

ignore is a stupid command that does not know any semantic of it's value (i.e. it can't glob). ignore read-only works.

@rusty-snake commented on GitHub (Mar 2, 2021): `ignore` is a stupid command that does not know any semantic of it's value (i.e. it can't glob). `ignore read-only` works.

gitea-mirror commented

2026-05-05 09:11:37 -06:00

Author

Owner

@vinc17fr commented on GitHub (Mar 2, 2021):

So I think that what I'm seeking for is some simple script that does

firejail --ignore=read-only --noblacklist='${HOME}/*' --private="$1" zsh

@vinc17fr commented on GitHub (Mar 2, 2021): So I think that what I'm seeking for is some simple script that does firejail --ignore=read-only --noblacklist='${HOME}/*' --private="$1" zsh

gitea-mirror commented

2026-05-05 09:11:37 -06:00

Author

Owner

@reinerh commented on GitHub (Mar 2, 2021):

Maybe ignore can be extended to support globs? Or match every line that contains a specified prefix?

@reinerh commented on GitHub (Mar 2, 2021): Maybe `ignore` can be extended to support globs? Or match every line that contains a specified prefix?

gitea-mirror commented

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

Author

Owner

@vinc17fr commented on GitHub (Mar 2, 2021):

Or perhaps a noread-only option, just like one has noblacklist?

A HAS_PRIVATE conditional would be useful, e.g. to have

?HAS_PRIVATE: ignore read-only
?HAS_PRIVATE: noblacklist ${HOME}/*

in default.local (or in some other profile).

@vinc17fr commented on GitHub (Mar 2, 2021): Or perhaps a `noread-only` option, just like one has `noblacklist`? A `HAS_PRIVATE` conditional would be useful, e.g. to have ``` ?HAS_PRIVATE: ignore read-only ?HAS_PRIVATE: noblacklist ${HOME}/* ``` in `default.local` (or in some other profile).

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Mar 3, 2021):

Or perhaps a noread-only option, just like one has noblacklist?

We have read-write. Unlike (no)blacklist it works with subpaths too.

# ~/writeable is writeable
read-only ${HOME}
read-write ${HOME}/writeable

# ~ is writeable
read-only ${HOME}
read-write ${HOME}

However, you still need ignore read-only ... if the ro comes abter the rw.

@rusty-snake commented on GitHub (Mar 3, 2021): > Or perhaps a noread-only option, just like one has noblacklist? We have `read-write`. Unlike `(no)blacklist` it works with subpaths too. ``` # ~/writeable is writeable read-only ${HOME} read-write ${HOME}/writeable # ~ is writeable read-only ${HOME} read-write ${HOME} ``` However, you still need `ignore read-only ...` if the ro comes abter the rw.

gitea-mirror commented

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

Author

Owner

@rusty-snake commented on GitHub (Aug 4, 2021):

I'm closing here due to inactivity, please fell free to request to reopen if you have more questions.

@rusty-snake commented on GitHub (Aug 4, 2021): I'm closing here due to inactivity, please fell free to request to reopen if you have more questions.

Rows
Columns

[GH-ISSUE #4026] --private and $HOME #2507