#1016015 firejail: The --read-write option fails to enable file mods to persist after the sandbox is gone

Package:
firejail
Source:
firejail
Description:
sandbox to restrict the application environment
Submitter:
anonymous coward
Date:
2023-01-07 19:21:03 UTC
Severity:
normal
Tags:
#1016015#5
Date:
2022-07-25 10:31:56 UTC
From:
To:
The command tootle was first executed outside firejail to establish a
working config file. This was motivated to work around bug
1015816. After tootle proved to function outside of firejail, it was
relaunched within firejail as follows:

  $ firejail --net=vnet0 --dns="$(ip address show dev vnet0 | awk '/inet\>/{gsub(/[/].*/,""); print $2 }')"\
             --env=XDG_CONFIG_HOME="$HOME"/my_config_files\
             --whitelist="$(readlink $HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
             --noblacklist="$(readlink $HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
             --read-write="$(readlink $HOME/.config)"com.github.bleakgrey.tootle/accounts.json\
             tootle

$HOME/.config is a symblic link to "$HOME"/my_config_files, and the
above configuration is crafted to ensure that firejail receives no
references to a symbolic file or directory.

Tootle was able to read the config file and make use of it within
firejail. Tootle was also able to update the config file during that
session, proven by its ability to add new accounts and interact with
them. But when the session ended, the config file updates were not
persistent and new accounts were lost.

Note that “tootle” and “toot” (mentioned in bug 1015816) are two
completely different applications, though they both serve the same
purpose.  Also note that bug 1015816 is very similar. The difference
is that in bug 1015816 the config file cannot be created, while the
bug herein reports that modifications to an existing config file do
not persist across sessions.  The bug herein may boil down to the same
bug affecting the same code as 1015816 (investigation needed).

#1016015#12
Date:
2023-01-07 19:11:37 UTC
From:
To:
Hi,

I just tried to reproduce it with firejail from bullseye (0.9.64.4), but
could not reproduce your problem.
I used a bit simplified approach:

As you can see, firejail does not prevent something inside the jail from
modifying the file, and the modifications persist after the jail is
closed.
I think something else is happening on your system. Were you using the
--private= option by chance, which creates a temporary home directory?

Please provide an example that is easier to reproduce and debug.

Kind regards,
  Reiner