Package: firejail
Version: 0.9.64.4-2
Followup-For: Bug #1015816
X-Debbugs-Cc: [email protected]
To cover all bases, I also tried enabling the read-write perms,
effectively running:
$ firejail --env=XDG_CONFIG_HOME="$HOME"/my_config_files\
--whitelist="$(readlink $HOME/.config)"toot/config.json\
--noblacklist="$(readlink $HOME/.config)"toot/config.json\
--profile=<(printf '%s\n' 'mkdir ~/tools/conf/toot')\
--read-write="$HOME"/my_config_files/toot\
--read-write="$HOME"/my_config_files/toot/config.json\
toot login
It made no difference. It still just leaves the empty directory
"$HOME"/my_config_files/toot.
As a possible secondary bug in the docs, the man page contains:
===8<------------------------------
--read-write=dirname_or_filename
Set directory or file read-write. Only files or directories belonging
to the current user are allowed for this operation.
File globbing is supported, see FILE GLOBBING section for more
details. Example:
$ mkdir ~/test
$ touch ~/test/a
$ firejail --read-only=~/test --read-write=~/test/a
===8<------------------------------
The man page does not state what the default perms are. The whitelist
option in the man page says: “Modifications to whitelisted files are
persistent”. This seems to imply that the read-write option is the
default setting on whitelisted dirs, but makes no mention of what
happens if read-write is used on a non-whitelisted dir. The example
given somewhat implies that read-write is useful when giving different
perms to a subdir than the parent dir. But it does not outright state
this so users are left guessing.
I should also say it’s unclear whether the noblacklist option is
useful or redundant. Does --whitelist imply --noblacklist
automatically? The man page should make that clear.
