chromium: different instances can talk to each other when --noprofile is used

[Flashwalker]

Description

Don't know bug or feature and it's intended, but:

I have a browser installed via Flatpak - one build version (e.g. v.109) And i have the same browser as Appimage - another build version (e.g. v.107)

And if i run a Flatpak one (v.109) like this:

 $ flatpak run --branch=stable --arch=x86_64 --command=/app/bin/chromium --file-forwarding com.github.Eloston.UngoogledChromium @@u \
    --user-data-dir=/home/user/.config/ungoogled-chromium \
    --profile-directory=Default \
    --class=ungoogled-chromium-flatpak \
    --name=ungoogled-chromium-flatpak @@

and then i start Appimage one (v.107) like this with --noprofile and with another browser --profile-directory:

 $ firejail --env=DESKTOPINTEGRATION=appimaged --noprofile --appimage ~/bin/ungoogled-chromium_107.0.5304.110-1.1.AppImage \
    --user-data-dir=/home/user/.config/ungoogled-chromium \
    --profile-directory=Custom \
    --class=ungoogled-chromium-appimage \
    --name=ungoogled-chromium-appimage

I get:

Parent pid 2359091, child pid 2359092

** Warning: dropping all Linux capabilities and setting NO_NEW_PRIVS prctl **

Mounting appimage type 2
Child process initialized in 49.49 ms
[5:16:0202/221313.254326:ERROR:file_path_watcher_inotify.cc(331)] inotify_init() failed: Too many open files (24)
Opening in existing browser session.

Thus, a browser running via Appimage with --noprofile actually works like one running through Flatpak. An existing browser session, launched by Flatpak, has been reused. And if i open About page in the Appimage running browser i can see the same build version as in Flatpak one - v.109. When, imho, it supposed to be firejailed v.107.

The same thing happens the other way around if I run Appimage variant first and then Flatpak variant. I can see that the version in About page is actualy from Appimage.

Is it intended to not sandbox app if --noprofile was passed? Or is it a Appimage specific behavior?

Steps to Reproduce

1. Run Flatpak flavour of a browser (e.g. v.109)
2. Run Appimage flavour of a browser (e.g. v.107) with --noprofile and with another browser --profile-directory
3. Open About page in Appimage one and you'll see v.109

Expected behavior

Firejailed Appimage runs in the sandbox separately from Flatpak

Actual behavior

Flatpak session reused

Environment

• Linux distribution and version: Ubuntu 22.04
• Firejail version: 0.9.66

Log

Parent pid 2359091, child pid 2359092

** Warning: dropping all Linux capabilities and setting NO_NEW_PRIVS prctl **

Mounting appimage type 2
Child process initialized in 49.49 ms
[5:16:0202/221313.254326:ERROR:file_path_watcher_inotify.cc(331)] inotify_init() failed: Too many open files (24)
Opening in existing browser session.

[kmk3]

• Firejail version: 0.9.66

Note that we do not maintain that version of firejail:

• https://github.com/netblue30/firejail/blob/master/SECURITY.md

Versions other than the latest usually have outdated profiles and may contain bugs and security vulnerabilities that were fixed in later versions.

See also:

• https://github.com/netblue30/firejail#installing

[kmk3]

@Flashwalker on Feb 2:

Is it intended to not sandbox app if --noprofile was passed?

Yes, it negates almost all of the security that firejail provides by default and is intended for debugging only.

The profile is where the sandbox restrictions are specified; see chromium.profile for example.

Expected behavior

Firejailed Appimage runs in the sandbox separately from Flatpak

Actual behavior

Flatpak session reused

If the problem still happens even without --noprofile, note that the instances may be communicating through dbus.

Firefox has a --no-remote CLI option to force starting a new instance.

Does Chromium have something similar?

You could also try blocking all dbus access with the following options:

dbus-user none
dbus-system none

This is safer but may break things like notifications and system tray icons.

[kmk3]

Is it intended to not sandbox app if --noprofile was passed?

Yes, that is exactly what that option is supposed to do.

It seems to be working as intended; closing as not a bug.

Thanks for the detailed report by the way; feel free to open more issues.