github-starred/firejail

Fork 0

mirror of https://github.com/netblue30/firejail.git synced 2026-05-15 14:16:14 -06:00

[GH-ISSUE #2617] ElectronMail cannot read or write config files #1657

New issue

Closed

opened 2026-05-05 08:18:28 -06:00 by gitea-mirror · 5 comments

gitea-mirror commented

2026-05-05 08:18:28 -06:00

Owner

Originally created by @ghost on GitHub (Mar 24, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2617

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

Originally created by @ghost on GitHub (Mar 24, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2617 The launch for [ElectronMail](https://github.com/vladimiry/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](https://github.com/netblue30/firejail/issues/2316). ## version firejail version 0.9.44.8

gitea-mirror closed this issue

2026-05-05 08:18:30 -06:00

gitea-mirror commented

2026-05-05 08:18:32 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 25, 2019):

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 commented on GitHub (Mar 25, 2019): 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.

gitea-mirror commented

2026-05-05 08:18:32 -06:00

Author

Owner

@smitsohu commented on GitHub (Mar 25, 2019):

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

@smitsohu commented on GitHub (Mar 25, 2019): I just realize there is no `noautopulse` in 0.9.44, it was added in 0.9.54.

gitea-mirror commented

2026-05-05 08:18:33 -06:00

Author

Owner

@ghost commented on GitHub (Mar 25, 2019):

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 commented on GitHub (Mar 25, 2019): 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.

gitea-mirror commented

2026-05-05 08:18:34 -06:00

Author

Owner

@ghost commented on GitHub (Mar 25, 2019):

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 commented on GitHub (Mar 25, 2019): 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.

gitea-mirror commented

2026-05-05 08:18:34 -06:00

Author

Owner

@ghost commented on GitHub (Mar 29, 2019):

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

@ghost commented on GitHub (Mar 29, 2019): Since the symbolic link issue is known and probably being worked in other issues, I'll close this one.

gitea-mirror referenced this issue

2026-05-05 10:12:33 -06:00

[PR #1657] [MERGED] Blacklist s3cmd and s3fs configs #4036

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1657

No description provided.

Rows
Columns