Firejail: "generic.profile" vs "default.profile" ambiguity

[vn971]

Please fix the ambiguity in either of the two directions.

Currently, firejail does ship a generic.profile file, and uses it when possible. On the other hand, firejail-profile manual says it will look for default.profile and server.profile files.

I find default.profile to be a better name, but generic is used already, so I guess I fully leave the choice to the author..

[netblue30]

From man firejail-profile:

      3. Use a default.profile file if the sandbox is started  by  a  regular
       user, or a server.profile file if the sandbox is started by root. Fire‐
       jail looks for these files in ~/.config/firejail directory, followed by
       /etc/firejail  directory [...]

later: You are right, I'll have to fix it. I'll change generic.profile to default profile!

[vn971]

Cool, thanks.:)

[netblue30]

Fixed, give it a try and let me know if you find anything else. I'll update the project webpages after I release the next version. Thanks.

[vn971]

Hm, I'm not sure it works. I'm testing the following scheme now:

• empty ~/.config/firejail directory
• the directory /etc/firejail contains only firejail.config and default.profile, with default.profile being generated by echo syntaxError > /etc/firejail/default.profile
• starting just the firejail without any additional command line arguments.

Expected: firejail failing to load itself because either the absence of a profile file, or because of incorrect syntaxt in it.

Observe: firejail actually loading itself. With empty rule set it seems.

[netblue30]

This is what I get:

$ ls /etc/firejail/
default.profile
$ firejail
Reading profile /etc/firejail/default.profile
Error: line 1 in /etc/firejail/default.profile is invalid

I would say it is the expected behavior. Not a bug.

[vn971]

Hm, that's strange.
It still does not work for me. I even removed both the /etc/firejail and ~/.config/firejail directories, but firejail still loads itself.

UPDATE: I re-compiled from master, but still observe the bug. I use ArchLinux with the following build "script": https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=firejail-git

[vn971]

Output for firejail --debug (first lines):

Command name #bash#
Attempting to find default.profile...
DISPLAY :0.0, 0
Using the local network stack
Parent pid 2477, child pid 2478
Initializing child process
Host network configured
PID namespace installed

[netblue30]

I have the new release out, give it a try and I'll reopen the bug if you still have problems.

[vn971]

Hi! Sorry for the late reply. The bug persists in recent versions of firejail, too. My directory structure and the observed bug are the same as described earlier: https://github.com/netblue30/firejail/issues/498#issuecomment-219276532

I'm using "firejail version 0.9.41" (as shown by firejail --version).

[netblue30]

OK, let's start from the beginning. On version 0.9.41, print here the commands you run and the output you get.

[vn971]

• mv ~/.config/firejail ~/.config/firejail2 (no output since it is a successful operation)
• delete all files in /etc/firejail except /etc/firejail/firejail.config
• start firejail .Without any additional command line arguments. Output:

Parent pid 21136, child pid 21137
Child process initialized
[myName@myCompName ~]$ 

• expected: failure

[vn971]

Alternative one-liner to show the bug:
firejail --noprofile --private --blacklist=/etc/firejail firejail
In this example, inner firejail should not have access to any profiles, so it should fail. In fact it does not fail.

[vn971]

@netblue30 Can you reproduce with the last (simple) example?

[netblue30]

$ firejail --noprofile --private --blacklist=/etc/firejail firejail
Parent pid 26416, child pid 26417

Child process initialized
Warning: an existing sandbox was detected. /bin/bash will run without any additional sandboxing features in a /bin/sh shell
$ 

It doesn't get a chance to fail, but it doesn't start either. It detects an existing sandbox, and it runs a normal bash session (see the warning).

If you force it to start with --force, this is what happens:

$ firejail --noprofile --private --blacklist=/etc/firejail firejail --force
Parent pid 26475, child pid 26476

Child process initialized
Warning: Firejail configuration file /etc/firejail/firejail.config not found

Parent is shutting down, bye...
$

So it fails, as it should be.

[vn971]

@netblue30 indeed. I have to write it a bit differently. This command still shows the bug:
firejail --noprofile --private --blacklist=/etc/firejail/default.profile firejail --force

[netblue30]

$ firejail --noprofile --private --blacklist=/etc/firejail/default.profile firejail --force
Parent pid 27707, child pid 27708

Child process initialized
Error: cannot open profile file /etc/firejail/default.profile

Parent is shutting down, bye...

It doesn't find a default.profile and it is shutting down. Is this a bug? You can add --noprofile at the end of the command and it will start.

[vn971]

@netblue30 sorry again, I forgot my computer does not have the file ("/etc/firejail/default.profile"), so my --blacklist behaves differently on other computers.

If your patience has not been spent already yet... To reproduce the bug on a fresh environment, the following is needed:

mv /etc/firejail/default.profile /etc/firejail/default2.profile
firejail --noprofile --private firejail --force

Or, alternatively, this:

mv ~/.config/firejail ~/.config/firejail2
mv /etc/firejail/default.profile /etc/firejail/default2.profile
firejail

[netblue30]

If your patience has not been spent already yet...

No problem, keep going. It usually ends up with me fixing some hard to catch bug. This is what I do:

$ sudo mv /etc/firejail/default.profile /etc/firejail/default2.profile
$ firejail --noprofile --private firejail
Parent pid 24561, child pid 24562

Child process initialized
$

So far so good. Firejail doens't care /etcfirejail/default.profile is missing because it was told not to care by --noprofile. Then I run the second command:

$ firejail --force
Parent pid 7, child pid 8

Child process initialized
$

This one shouldn't succeed because the default profile is missing. You are right, it is a bug!

[netblue30]

Fixed in git, thanks!

[vn971]

@netblue30 indeed it works now. Thanks!