[GH-ISSUE #4206] [NOT SURE IF BUG] multiple instances of same application started via "firejail --private $PROG" not isolated but share data

gitea-mirror commented

2026-05-05 09:14:55 -06:00

Owner

Originally created by @mirko on GitHub (Apr 21, 2021).
Original GitHub issue: https://github.com/netblue30/firejail/issues/4206

I'm starting a firefox instance explicitly via firejail --private firefox and start browsing.
Then I'm starting a second firefox instance again via firejail --private firefox while the first one is still running.
A bit confused I noticed, that while typing an URL it autocompletes to sites I browsed in the first instance.

Bug and expected behavior

Describe the bug.
The instances started via firejail --private $PROG (in my case PROG=firefox) are not isolated from each other and share data.
What did you expect to happen?
Every instance of $PROG started via firejail --private being fresh and isolated from other instances.

No profile and disabling firejail

What changed calling firejail --private --noprofile firefox in a terminal?
nothing

Reproduce
Steps to reproduce the behavior:

Run in bash firejail --private firefox
browse, set cookies, fill cache
Run in bash - in addition to (1) - firejail --private firefox and access data stored by instance started in (1)

Environment

Linux distribution and version (ie output of lsb_release -a, screenfetch or cat /etc/os-release)

PRETTY_NAME="Debian GNU/Linux bullseye/sid"
NAME="Debian GNU/Linux"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

Firejail version (output of firejail --version) exclusive or used git commit (git rev-parse HEAD)
firejail version 0.9.64.4

If it's not a bug, on a scale from 1 to 10: how silly is it me being surprised by this behaviour?

Originally created by @mirko on GitHub (Apr 21, 2021). Original GitHub issue: https://github.com/netblue30/firejail/issues/4206 I'm starting a firefox instance explicitly via `firejail --private firefox` and start browsing. Then I'm starting a second firefox instance again via `firejail --private firefox` while the first one is still running. A bit confused I noticed, that while typing an URL it autocompletes to sites I browsed in the first instance. **Bug and expected behavior** - Describe the bug. The instances started via `firejail --private $PROG` (in my case PROG=firefox) are not isolated from each other and share data. - What did you expect to happen? Every instance of $PROG started via `firejail --private` being fresh and isolated from other instances. **No profile and disabling firejail** - What changed calling `firejail --private --noprofile firefox` in a terminal? nothing **Reproduce** Steps to reproduce the behavior: 1. Run in bash `firejail --private firefox` 2. browse, set cookies, fill cache 3. Run in bash - in addition to (1) - `firejail --private firefox` and access data stored by instance started in (1) **Environment** - Linux distribution and version (ie output of `lsb_release -a`, `screenfetch` or `cat /etc/os-release`) ``` PRETTY_NAME="Debian GNU/Linux bullseye/sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/" ``` - Firejail version (output of `firejail --version`) exclusive or used git commit (`git rev-parse HEAD`) `firejail version 0.9.64.4` If it's not a bug, on a scale from 1 to 10: how silly is it me being surprised by this behaviour?

gitea-mirror closed this issue

2026-05-05 09:14:56 -06:00

gitea-mirror commented

2026-05-05 09:14:58 -06:00

Author

Owner

@ghost commented on GitHub (Apr 21, 2021):

The instances started via firejail --private $PROG (in my case PROG=firefox) are not isolated from each other and share data.

There's some confusion here. Both issue title and the above issue description seem to suggest you are seeing this behavior with all applications. Yet IMO this is mainly focussing on firefox, which has a set of parameters of its own, like --no-remote and --new-instance that explain what you're seeing. So no, IMO this isn't a bug in firejail, but a lack of understanding the application you're trying to sandbox (Firefox). See #1319 for example.

To be clear, can you provide another example of an application that shares data besides running multiple firefox instances? On a side note, we have discussions too now, so when unsure if you have a bug, might be more appropriate to open a discussion thread instead.

Is it's not a bug, on a scale from 1 to 10: how silly is it me being surprised by this behaviour?

Hard to answer. It's always good practice to get familiar with the ins and outs of the applications you want to sandbox. In this case I'd suggest running firefox --help and consult the upstream help pages if some of these app-internal options are unclear.

@ghost commented on GitHub (Apr 21, 2021): > The instances started via firejail --private $PROG (in my case PROG=firefox) are not isolated from each other and share data. There's some confusion here. Both issue title and the above issue description seem to suggest you are seeing this behavior with _all_ applications. Yet IMO this is mainly focussing on firefox, which has a set of parameters of its own, like `--no-remote` and `--new-instance` that explain what you're seeing. So no, IMO this isn't a bug in firejail, but a lack of understanding the application you're trying to sandbox (Firefox). See #1319 for example. To be clear, can you provide another example of an application that shares data besides running multiple firefox instances? On a side note, we have [discussions](https://github.com/netblue30/firejail/discussions) too now, so when unsure if you have a bug, might be more appropriate to open a discussion thread instead. > Is it's not a bug, on a scale from 1 to 10: how silly is it me being surprised by this behaviour? Hard to answer. It's always good practice to get familiar with the ins and outs of the applications you want to sandbox. In this case I'd suggest running `firefox --help` and consult the upstream help pages if some of these app-internal options are unclear.

gitea-mirror commented

2026-05-05 09:14:59 -06:00

Author

Owner

@mirko commented on GitHub (Apr 22, 2021):

Hey, thanks for your answer.

Yes, I'm atm only seeing this behaviour with firefox, which obviously doesn't mean it's only happening with firefox.

Since you're using the term "sandboxing" yourself, I have to admit I indeed would expect an application being sandboxed/jailed, it being isolated to a degree that above described behaviour is /not/ happening when sandboxing it with the most restricting option the sandboxing suite provides me with (in this case firejail --private) - regardless of the IPC features the to be sandboxed application implements.

As you're saying it's not firejail but firefox, I have to assume firejail is not sandboxing the applications I'm using firejail on to the degree I expected firejail to do.

Don't get me wrong, I'm not blaming / fingerpointing here and quite well understand what's happening on the technical level here, but it seems I used firejail with wrong assumptions, mainly, that the processes are being isolated from each other and only share a bare minimum of resources necessary for their basic functionality (audio, video on the higher level, potentially a couple of sockets (e.g. dbus, etc.) on the lower level), but do not do IPC / expose such data to unrelated processes (*).

And I'm kind of afraid it's not only me having this assumption.

(*) I know that in this very scenario it's not "processes" but one single process and calling [firejail --private] firefox here just triggers the running instance to open a new window. But from the user's perspective and its assumptions the behavioural implications can be pretty severe.

@mirko commented on GitHub (Apr 22, 2021): Hey, thanks for your answer. Yes, I'm atm only seeing this behaviour with firefox, which obviously doesn't mean it's only happening with firefox. Since you're using the term "sandboxing" yourself, I have to admit I indeed would expect an application being sandboxed/jailed, it being isolated to a degree that above described behaviour is /not/ happening when sandboxing it with the most restricting option the sandboxing suite provides me with (in this case `firejail --private`) - regardless of the IPC features the to be sandboxed application implements. As you're saying it's not firejail but firefox, I have to assume firejail is not sandboxing the applications I'm using firejail on to the degree I expected firejail to do. Don't get me wrong, I'm not blaming / fingerpointing here and quite well understand what's happening on the technical level here, but it seems I used firejail with wrong assumptions, mainly, that the processes are being isolated from each other and only share a bare minimum of resources necessary for their basic functionality (audio, video on the higher level, potentially a couple of sockets (e.g. dbus, etc.) on the lower level), but do not do IPC / expose such data to unrelated processes (*). And I'm kind of afraid it's not only me having this assumption. (*) I know that in this very scenario it's not "processes" but one single process and calling `[firejail --private] firefox` here just triggers the running instance to open a new window. But from the user's perspective and its assumptions the behavioural implications can be pretty severe.

gitea-mirror commented

2026-05-05 09:15:00 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 22, 2021):

As @glitsj16 pointed out, something worth trying would be to start Firefox with --no-remote. Alternatively you could also try the Firejail option --env=MOZ_NO_REMOTE=1, the outcome should be exactly the same.

Firejail could set the MOZ_NO_REMOTE environment variable also automatically. In fact it's already in the source, it just was never uncommented. Not sure about the reason, but I suppose it's because this behaviour is (or used to be) quite convenient when opening links in email clients.
6b4f6f4834/src/firejail/env.c (L123)

@smitsohu commented on GitHub (Apr 22, 2021): As @glitsj16 pointed out, something worth trying would be to start Firefox with `--no-remote`. Alternatively you could also try the Firejail option `--env=MOZ_NO_REMOTE=1`, the outcome should be exactly the same. Firejail could set the MOZ_NO_REMOTE environment variable also automatically. In fact it's already in the source, it just was never uncommented. Not sure about the reason, but I suppose it's because this behaviour is (or used to be) quite convenient when opening links in email clients. https://github.com/netblue30/firejail/blob/6b4f6f4834ab629efc99a64879cb62335afe7f36/src/firejail/env.c#L123

gitea-mirror commented

2026-05-05 09:15:01 -06:00

Author

Owner

@ghost commented on GitHub (Apr 22, 2021):

Maybe we need some kind of OSD-notification system to inform users of these kinds of potential issues/unexpected behaviours. It's fine to have error and warning messages in the code, but you need to be in a terminal starting apps from CLI with --ignore=quiet to catch any of this, let alone understand what's being communicated. And allthough we don't have data on how people use firejail on a daily basis, I think it's pretty safe to assume a 'regular' user is GUI-oriented. Quite a complex topic all in all. But it never hurts to contemplate improvements...

@ghost commented on GitHub (Apr 22, 2021): Maybe we need some kind of OSD-notification system to inform users of these kinds of potential issues/unexpected behaviours. It's fine to have error and warning messages in the code, but you need to be in a terminal starting apps from CLI with --ignore=quiet to catch any of this, let alone understand what's being communicated. And allthough we don't have data on how people use firejail on a daily basis, I think it's pretty safe to assume a 'regular' user is GUI-oriented. Quite a complex topic all in all. But it never hurts to contemplate improvements...

gitea-mirror commented

2026-05-05 09:15:02 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 22, 2021):

@mirko If you wonder how to interrupt the IPC by means of sandboxing, you may want to give Firejail's --x11=* options a try.

@smitsohu commented on GitHub (Apr 22, 2021): @mirko If you wonder how to interrupt the IPC by means of sandboxing, you may want to give Firejail's `--x11=*` options a try.

gitea-mirror commented

2026-05-05 09:15:04 -06:00

Author

Owner

@ghost commented on GitHub (Apr 22, 2021):

@smitsohu I'm wondering if MOZ_NO_REMOTE (and potentially other) environment variables could be moved from the code to the profiles themselves. Or at least also included in (some) profiles, so users would be more aware of their relevance. Any thoughts on that?

@ghost commented on GitHub (Apr 22, 2021): @smitsohu I'm wondering if MOZ_NO_REMOTE (and potentially other) environment variables could be moved from the code to the profiles themselves. Or at least also included in (some) profiles, so users would be more aware of their relevance. Any thoughts on that?

gitea-mirror commented

2026-05-05 09:15:05 -06:00

Author

Owner

@mirko commented on GitHub (Apr 22, 2021):

If you wonder how to interrupt the IPC by means of sandboxing, you may want to give Firejail's --x11=* options a try.

Given I'm running wayland and using firefox natively within wayland (MOZ_ENABLE_WAYLAND=1), I believe the --x11-options won't have any effect when not residing in X11 environments(?)

@mirko commented on GitHub (Apr 22, 2021): > If you wonder how to interrupt the IPC by means of sandboxing, you may want to give Firejail's --x11=* options a try. Given I'm running wayland and using firefox natively within wayland (`MOZ_ENABLE_WAYLAND=1`), I believe the `--x11`-options won't have any effect when not residing in X11 environments(?)

gitea-mirror commented

2026-05-05 09:15:06 -06:00

Author

Owner

@mirko commented on GitHub (Apr 22, 2021):

Just for clarification, what - on technical level - makes firefox actually detecting there's already an instance running and hence deciding to communicate via what exactly with the first instance so it triggers the opening of a new window there? SHM? D-Bus? Some (other kind of) socket?

@mirko commented on GitHub (Apr 22, 2021): Just for clarification, what - on technical level - makes firefox actually detecting there's already an instance running and hence deciding to communicate via what exactly with the first instance so it triggers the opening of a new window there? SHM? D-Bus? Some (other kind of) socket?

gitea-mirror commented

2026-05-05 09:15:08 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 22, 2021):

Given I'm running wayland and using firefox natively within wayland (MOZ_ENABLE_WAYLAND=1), I believe the --x11-options won't have any effect when not residing in X11 environments(?)

Ok, then we have a new issue 😃

Just for clarification, what - on technical level - makes firefox actually detecting there's already an instance running

Looks like they are using D-Bus on Wayland.

@smitsohu commented on GitHub (Apr 22, 2021): > Given I'm running wayland and using firefox natively within wayland (MOZ_ENABLE_WAYLAND=1), I believe the --x11-options won't have any effect when not residing in X11 environments(?) Ok, then we have a new issue :smiley: > Just for clarification, what - on technical level - makes firefox actually detecting there's already an instance running Looks like they are using D-Bus on Wayland.

gitea-mirror commented

2026-05-05 09:15:08 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 22, 2021):

@glitsj16 That's an interesting idea. It should be possible at least for those environment variables that don't have to be computed.

And maybe excluding KDE_FORK_SLAVES because it has small security implication on its own (controls if code runs inside or outside the sandbox if D-Bus is not disabled); so in this case include in default profiles would be somewhat more unreliable than the way it works currently.

@smitsohu commented on GitHub (Apr 22, 2021): @glitsj16 That's an interesting idea. It should be possible at least for those environment variables that don't have to be computed. And maybe excluding KDE_FORK_SLAVES because it has small security implication on its own (controls if code runs inside or outside the sandbox if D-Bus is not disabled); so in this case `include` in default profiles would be somewhat more unreliable than the way it works currently.

gitea-mirror commented

2026-05-05 09:15:08 -06:00

Author

Owner

@rusty-snake commented on GitHub (Apr 22, 2021):

RELATED: #4050

Looks like they are using D-Bus on Wayland.

#3290

MOZ_NO_REMOTE=1

Gives the UX somebody expects but does not tight the sandbox.

@rusty-snake commented on GitHub (Apr 22, 2021): RELATED: #4050 > Looks like they are using D-Bus on Wayland. #3290 > MOZ_NO_REMOTE=1 Gives the UX somebody expects but does not tight the sandbox.

gitea-mirror commented

2026-05-05 09:15:08 -06:00

Author

Owner

@smitsohu commented on GitHub (Apr 22, 2021):

@glitsj16 @rusty-snake Probably you are right, it is more an issue in Firefox.

I'm wondering if MOZ_NO_REMOTE (and potentially other) environment variables could be moved from the code to the profiles themselves. Or at least also included in (some) profiles, so users would be more aware of their relevance. Any thoughts on that?

How about adding the FAQ as a comment to the profile?

The setup suggested in the FAQ though still leaves the possibility of lesser trusted Firefox instances (say an online casino profile) messing with more trusted instances (say an online banking profile) at filesystem level, because all instances whitelist the same ~/.mozilla directory.

Strict isolation would require something like

--private or
--private-home=.mozilla or
--tmpfs=~/.mozilla --tmpfs=~/.cache/mozilla (in order to keep the real Downloads folder accessible) or
--private= with per profile home directories
somehow managing profile directories outside of ~/.mozilla and using different Firefox launchers

all of which doesn't fit well in a default profile.

@smitsohu commented on GitHub (Apr 22, 2021): @glitsj16 @rusty-snake Probably you are right, it is more an issue in Firefox. > I'm wondering if MOZ_NO_REMOTE (and potentially other) environment variables could be moved from the code to the profiles themselves. Or at least also included in (some) profiles, so users would be more aware of their relevance. Any thoughts on that? How about adding the [FAQ](https://github.com/netblue30/firejail/wiki/Frequently-Asked-Questions#how-do-i-run-two-instances-of-firefox) as a comment to the profile? The setup suggested in the FAQ though still leaves the possibility of lesser trusted Firefox instances (say an online casino profile) messing with more trusted instances (say an online banking profile) at filesystem level, because all instances whitelist the same ~/.mozilla directory. Strict isolation would require something like - `--private` or - `--private-home=.mozilla` or - `--tmpfs=~/.mozilla --tmpfs=~/.cache/mozilla` (in order to keep the real Downloads folder accessible) or - `--private=` with per profile home directories - somehow managing profile directories outside of ~/.mozilla and using different Firefox launchers all of which doesn't fit well in a default profile.

gitea-mirror commented

2026-05-05 09:15:09 -06:00

Author

Owner

@chiraag-nataraj commented on GitHub (May 5, 2021):

* somehow managing profile directories outside of ~/.mozilla and using different Firefox launchers

I actually set this up, along with a mechanism for generating temporary Firefox profiles (cleaned on exit), using my private-profile.sh and this configuration file.

@mirko, you may be interested in that script. Because I store all of my profiles in ~/.config/mozilla/firefox, just running plain firefox (or even plain firejail firefox) will create a brand new profile and it will not know about the existing permanent and temporary profiles.

@chiraag-nataraj commented on GitHub (May 5, 2021): > * somehow managing profile directories outside of ~/.mozilla and using different Firefox launchers I actually set this up, along with a mechanism for generating temporary Firefox profiles (cleaned on exit), using my [private-profile.sh](https://raw.githubusercontent.com/chiraag-nataraj/firejail-profiles/master/private-profile.sh) and [this configuration file](https://raw.githubusercontent.com/chiraag-nataraj/firejail-profiles/master/private-profiles/firefox.private). @mirko, you may be interested in that script. Because I store all of my profiles in `~/.config/mozilla/firefox`, just running plain `firefox` (or even plain `firejail firefox`) will create a brand new profile and it will not know about the existing permanent and temporary profiles.

gitea-mirror commented

2026-05-05 09:15:09 -06:00

Author

Owner

@rusty-snake commented on GitHub (Jun 10, 2021):

I'm closing here due to inactivity, please fell free to request to reopen if you have more questions.

@rusty-snake commented on GitHub (Jun 10, 2021): I'm closing here due to inactivity, please fell free to request to reopen if you have more questions.

Rows
Columns

[GH-ISSUE #4206] [NOT SURE IF BUG] multiple instances of same application started via "firejail --private $PROG" not isolated but share data #2579