Doc about how clashing/overlapping options are combined

[jonleivent]

Is there any documentation about how various firejail options that appear in profiles, include files in those profiles, and on the command line are combined when they clash or overlap?

It would be best if doc about this included:

• the priority of various .profile/.inc/.local files and the command line
• the order of appearance of options in files and on the command line
• which options clash or overlap with which others
• what happens in clashing or overlapping cases
• do certain options have priority over others
• which options can safely be combined to create useful states
• how options that intentionally override others, such as ignore, are affected by their placement

Relates to:

• docs: manpage should explain precedence of CLI options vs profile settings #6358
• docs: add precedence info to manpage & fix noblacklist example #6359

[rusty-snake]

• the priority of various .profile/.inc/.local files and the command line
• the order of appearance of options in files and on the command line

The options are parsed/handled in the order they appear: {command-line} {--profile} {rest of command-line}. If --noprofile is not used, {rest of command-line} is empty. In a profile they are parsed/handled in order too.

Example

foo.profile:

noA
include bar.inc
noB

bar.inc

noBAR

firejail --noC --profile=foo --noD foo: noC noA noBAR noB noD
firejail --noC --noD foo: noC noD noA noBAR noB

how options that intentionally override others, such as ignore, are affected by their placement

Since parsing is done in order, they only affect later options.

[rusty-snake]

that means that users cannot override .profile options?

ignore <LINE> does work for every following line. So you can ingore everything that follows, every option in .profile (except for quiet #3503).

If we would include .local at the end, you could not use noblacklist, ignore, ... You could not override nonewprivs, blacklist, ...

[jonleivent]

OK, so the expectation then is that .local files contain a bunch of ignore options targeting the .profile. Also that app.local can contain ignore options targeting globals.local, since app.local is typically included first.

How do ignore options work with respect to globing? Does an ignore option have to match the targeted option precisely via string compare?

[rusty-snake]

so the expectation then is that .local files contain a bunch of ignore options targeting the .profile.

IMHO the expectation is that .local contain additions (e.g. whitelist ${HOME}/I_need_this_too). The options in the profile are the to make the profile tight but should break the program. Why would somebody want to ignore a bunch of them?

For me:

$ grep -vE "^#" ~/.config/firejail/* --no-filename | grep -E ".+" | wc -l
603
$ grep ignore ~/.config/firejail/* | wc -l                             
16

Does an ignore option have to match the targeted option precisely via string compare?

It's a simple, stupid string comparison without any semantic that is done before parsing an option. For the exact rules however you need to study the code.

[jonleivent]

Why would somebody want to ignore a bunch of them?

I thought that's what you implied by your previous answer to my question about how to deal with clashes between what users want in their .local files vs. what is in the .profile. Hence why .local files are loaded early, so that the ignores (and aliases of ignore like noblacklist) can impact the .profile. Did I confuse that?

One example that I do is I have disable-mnt in my globals.local, then I have a few ignore disable-mnt in app.local files. Another: I have ignore nodvd in my virtualbox.local so it can load isos from dvds.

For the exact rules however you need to study the code.

It looks in the code like it does a quasi-prefix string compare, where the prefix can match up to a space in the target or the whole target. Hence "ignore foo" would match "foo bar" but not "foo-bar". That makes sense.

Do ignores in the profiles impact command-line processing? I would kind of expect that what is on a command line following the loading of a profile always overrides whatever is in the profile, even if the profile has some ignores (which may just be there to impact other parts of the profile tree, such as when a .local ignores a .profile option). Or, does the user have to "ignore=ignore foo" on the command line prior to the --profile in order to then add "foo" back in later in the command line?

[rusty-snake]

Do ignores in the profiles impact command-line processing?

command-line is handled first (see above) and ignore only affects later options.

Or, does the user have to "ignore=ignore foo" on the command line prior to the --profile in order to then add "foo" back in later in the command line?

(OT: You can even write ignore ignore ignore ignore ignore foo 😆 )

If you do firejail --foo --ignore=foo --foo, foo, the first --foo sets foo and because ignore has no semantic functionality, it can no unset foo.