--private and $HOME

[reinerh]

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?

[rusty-snake]

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.

[vinc17fr]

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?

[rusty-snake]

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).

[reinerh]

@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.

[vinc17fr]

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.

[reinerh]

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).

[vinc17fr]

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.

[reinerh]

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.

[rusty-snake]

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

[vinc17fr]

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.

[rusty-snake]

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.

[vinc17fr]

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

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

[reinerh]

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

[vinc17fr]

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).

[rusty-snake]

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]

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