ElectronMail cannot read or write config files

[ghost]

The launch for ElectronMail is done this way:

firejail\
         --noblacklist="$HOME"/.config/electron-mail\
         --whitelist="$HOME"/.config/electron-mail\
         --debug-blacklists --debug-whitelists --output="${fn_log}"\
         /usr/local/bin/electron-mail

ElectronMail has Chromium embedded in it. Config files are in "$HOME"/.config/electron-mail. The program runs as if it's a first launch with no configuration. When config parameters are entered they work for the session but when the firejail closes "$HOME"/.config/electron-mail still shows no updated files. Every time ElectronMail runs it's as if it's the first run. But when I run outside firejail the existing configuration is found and used.

The output log shows that the directory is whitelisted:

...
Replaced whitelist path: whitelist /home/user/apps/conf/electron-mail
Whitelisting /home/user/apps/conf/electron-mail
...

$HOME/.config/ is a symbolic link to $HOME/apps/conf/.

The /var/log/syslog file shows no attempts on blacklisted objects. I've also run with --noprofile and it makes no difference.

no tracelog

It's difficult to troubleshoot the problem because the --tracelog command is broken.

version

firejail version 0.9.44.8

[smitsohu]

Thanks for your report.

Two problems here: One is a limitation (or let's call it a bug) in how Firejail handles symbolic links and whitelisting.
Currently a symbolic link is only detected (and created) if the symbolic link is also the file to be whitelisted, or in other words if the last path element is the link. It probably would be good if Firejail could handle symlinks more generously; especially symlinked ~/.config directories seem to be not uncommon, for example see also #2329.

Once whitelisting is solved, you are going to run into a second problem, assuming your systems are using Pulseaudio.
To work around a bug in older Pulseaudio versions (#69), Firejail mounts a new ~/.config/pulse/client.conf file inside the sandbox. In order to not fall victim to symlink attacks, we have to exclude in a reliable way that ~/.config is a symbolic link, and print an error if that is the case.
However, this Pulseaudio bug has been fixed in version 10, so if pulseaudio --version returns 10 or higher, you actually don't need Firejail's workaround and you can disable it with noautopulse (put it in /etc/firejail/globals.local).
It probably would be good if Firejail could do something like this just automatically.

[smitsohu]

I just realize there is no noautopulse in 0.9.44, it was added in 0.9.54.

[ghost]

I got it to work simply by not using any lists:

firejail --noprofile /usr/local/bin/electron-mail

Although I guess there's no point in that because if I understand correctly there's effectively no sandboxing protection. In principle a good protection to add might be to use a netfilter that blocks connections to Google, since the Electronjs browser is Chromium we can expect it to attempt to phone home.

[ghost]

Firejail is actually detecting and mapping the symlink correctly, but still fails if the app tries to use the symlink. A better workaround is to force the app to use the non-symbolic path:

dir_default=$HOME/.config/electron-mail
dir_nonsym=$(readlink ${dir_default%/*})${dir_default##*/}
firejail --env=ELECTRON_MAIL_USER_DATA_DIR="$dir_nonsym"\
         --noblacklist="$dir_nonsym" --whitelist="$dir_nonsym"\
         /usr/local/bin/electron-mail

That works.

[ghost]

Since the symbolic link issue is known and probably being worked in other issues, I'll close this one.