mkdir in profile does not respect --private=<directory>

[pyamsoft]

Latest stable firejail: 0.9.44

The command line option --private=<directory> states that firejail uses the given directory as a new home.

--private=directory
      Use directory as user home.

      Example:
      $ firejail --private=/home/netblue/firefox-home firefox

This works fine, and all whitelist and blacklist commands work as expected with respect to the private directory. However, using mkdir in a profile incorrectly creates the directory in the real home.

You can observe this in the shipped Dropbox profile for example, which makes calls to mkdir in its profile:

firejail --private=/home/pyamsoft/dropboxtesting dropbox

You can observe similar errors in the shipped firefox profile.

firejail --private=/home/pyamsoft/firefoxtesting firefox

You will see that a Dropbox folder will be created in the actual home directory, instead of the private home at ~/dropboxtesting. You will also see the firefox directories like ~/.mozilla being created in the real home. I would expect that mkdir will respect the private home directory just as whitelist and blacklist do, so I believe this behavior to be a bug.

[valoq]

I can confirm the behaviour. Seems like a bug to me.

[netblue30]

Fixed, thanks for the bug.

[okcomputerik]

Although marked as fixed, I see the same behavior running firejail 0.9.44.8 with the dropbox profile. Am I missing something here? Thanks!

[netblue30]

I'll look into it, thanks.

[sunho0301]

Are there any updates on this issue?? I'm having the same problem.
Thanks!

[chiraag-nataraj]

Is this still an issue? If so, let's figure out what's going on :)

[chiraag-nataraj]

Yes, this is still an issue. The question becomes the following:
If we write mkdir ${HOME}/<somedir>, do we mean the real ${HOME} or what the sandbox will see as ${HOME}?

[chiraag-nataraj]

@netblue30 Is this intended behavior? If we use ${HOME} in, say, mkdir, do we want ${HOME} to be resolved after things like --private have been resolved or do we want to resolve it before those predicates? That will change the behavior as I understand it, and either one is fine as long as we document it.

[chiraag-nataraj]

Sorry to dredge up so many old issues, but @netblue30, is this intended behavior? If so, we can close. Otherwise, we should fix this.

[matu3ba]

@rusty-snake @chiraag-nataraj
If the folder does not exist, firejail prompts Error: invalid private directory and exists. If nesting of firejails is forbidden, the error could maybe be simplified to Error: folder not usable as private directory. However I am not sure about this.
Otherwise suggestion to close this.

[rusty-snake]

@matu3ba it's not about the private directory does not work. The mkdir does not respect it. Like this:

$ cat tmp.profile
mkdir ${HOME}/foo
private
mkdir ${HOME}/bar
$ firejail --profile=tmp.profile true
$ [ -e foo ] && echo "foo exists"
foo exists
$ [ -e bar ] && echo "bar exists"
bar exists

[vinc17fr]

In fact, mkdir creates a directory in both the real home directory and the sandbox. And mkfile has the same issue:

$ cat > .config/firejail/test.profile
mkdir ${HOME}/fj-dir
mkfile ${HOME}/fj-file
$ mkdir fj-priv
$ ls -d fj-dir fj-file fj-priv/*
ls: cannot access 'fj-dir': No such file or directory
ls: cannot access 'fj-file': No such file or directory
ls: cannot access 'fj-priv/*': No such file or directory
$ firejail --private=fj-priv --profile=test sh
Reading profile /home/vinc17/.config/firejail/test.profile
Parent pid 52414, child pid 52417
Child process initialized in 12.93 ms
$ exit
sh: 1: Cannot set tty process group (No such process)

Parent is shutting down, bye...
$ ls -d fj-dir fj-file fj-priv/*
fj-dir  fj-file  fj-priv/fj-dir  fj-priv/fj-file

[smitsohu]

To illustrate what probably was the reasoning behind this design, let's take Firefox. The profile uses whitelist in user home, so if the program is never run outside of Firejail, all application files and directories (~/.mozilla, ~/.cache/mozilla, ...) are ever created only in the tmpfs, and are always discarded when the sandbox shuts down. There will never be any persistence, which is not how whitelist is supposed to work, and is closer to what private is supposed to do.

One possible solution is to create needed files and directories beforehand as the user in the real file system, so that whitelist can properly bind mount them in the sandbox.

The downside is that some profiles create quite a clutter in the file system, which is also not so nice. As a workaround you can add

ignore mkfile
ignore mkdir

to /etc/firejail/globals.local and create files manually, or run applications once outside Firejail, which is usually sufficient to get all required directories and files.

[rusty-snake]

FTR: #4285

[smitsohu]

Maybe we could postpone mkdir and mkfileuntil after private option processing, but handle them before whitelist.

[colons]

hi. i don't know that this issue has any actual security consequences, but it is extremely disconcerting to see your home directory littered with directories related to something you launched with the promise that it'd be contained to a directory you specified. if nothing else, it's a violation of what --private says it'll do, and it requires active tidying up after it has its effect