[GH-ISSUE #1090] Weird issue with Audacious and Firefox with --private=directory

gitea-mirror commented

2026-05-05 06:33:40 -06:00

Owner

Originally created by @acrobat1 on GitHub (Feb 5, 2017).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1090

I've seen something very strange using Audacious and Firefox at the same time: first I've launched Audacious using Firejail, then Firefox in another sandbox with the --private=directory argument, using a private home folder as target for --private= .

Normally in this situation, when trying to reach the Firefox profile directory from the about:support page in the browser, you will get an error because the .mozilla directory that the browser is now using with --private= is not supposed to be accessed in this way : however, with Audacious running, it adds the actual path of this directory to a second playlist that opens in the already running sandboxed instance of Audacious and it even shows it in the desktop notification of the player.

I suspect it's some weird issue with dbus sockets, because when quitting Audacios and then launching it again with the net=none option and Firefox still running, the same action (clicking on Open Directory in about:support) will now bring up a second empty instance of Audacious (as opposed to adding the .mozilla path to a second playlist in the already running instance of the player) .

And it doesn't stop here, apparently: with the same instance of Firefox still running, if I quit Audacios completely and then click again Open Directory in about:support, a new empty and un-sandboxed instance of Audacious will pop up again, with the same path to the actual Firefox profile in use as argument (I've checked this with pgrep -afl audacious) .

Forgot to mention:

firejail version 0.9.44.8 in Debian Stable (0.9.44.8-1~bpo8+1 according to the package manager)
audacious 3.5-2

Originally created by @acrobat1 on GitHub (Feb 5, 2017). Original GitHub issue: https://github.com/netblue30/firejail/issues/1090 I've seen something very strange using Audacious and Firefox at the same time: first I've launched Audacious using Firejail, then Firefox in another sandbox with the **--private=directory** argument, using a private home folder as target for --private= . Normally in this situation, when trying to reach the Firefox profile directory from the about:support page in the browser, you will get an error because the .mozilla directory that the browser is now using with --private= is not supposed to be accessed in this way : however, with Audacious running, *it adds the actual path of this directory to a second playlist that opens in the already running sandboxed instance of Audacious* and it even shows it in the desktop notification of the player. I suspect it's some weird issue with dbus sockets, because when quitting Audacios and then launching it again with the net=none option and Firefox still running, the same action (clicking on Open Directory in about:support) will now bring up a second empty instance of Audacious (as opposed to adding the .mozilla path to a second playlist in the already running instance of the player) . And it doesn't stop here, apparently: with the same instance of Firefox still running, if I quit Audacios completely and then click again Open Directory in about:support, a new empty and un-sandboxed instance of Audacious will pop up again, with the same path to the actual Firefox profile in use as argument (I've checked this with pgrep -afl audacious) . Forgot to mention: * firejail version 0.9.44.8 in Debian Stable (0.9.44.8-1~bpo8+1 according to the package manager) * audacious 3.5-2

gitea-mirror

2026-05-05 06:33:40 -06:00

closed this issue
added the
information_old
label

gitea-mirror commented

2026-05-05 06:33:47 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 5, 2017):

I'll try it out, thanks.

@netblue30 commented on GitHub (Feb 5, 2017): I'll try it out, thanks.

gitea-mirror commented

2026-05-05 06:33:51 -06:00

Author

Owner

@acrobat1 commented on GitHub (Feb 21, 2017):

One more thing I've noted: sometimes (I have no idea when it exactly does that) this goes as far as creating an audaciuos directory somewhere inside the private firejail directory, it think in .config.

@acrobat1 commented on GitHub (Feb 21, 2017): One more thing I've noted: sometimes (I have no idea when it exactly does that) this goes as far as creating an audaciuos directory somewhere inside the private firejail directory, it think in .config.

gitea-mirror commented

2026-05-05 06:33:54 -06:00

Author

Owner

@netblue30 commented on GitHub (Feb 21, 2017):

I am getting the same thing, or something very close to what you have!

when trying to reach the Firefox profile directory from the about:support page in the browser, you will get an error because the .mozilla directory that the browser is now using with --private= is not supposed to be accessed in this way

Actually when you press Open Profile in about:support, Firefox tries to communicate to an existing file manager. If you are running a desktop environment (as opposed to a simple window manager), the file manager is always there. It was started by default when the desktop manager was initialized.

I suspect the communication is over dbus, but it could also also be over a regular Unix socket. It all depends on the file manager - apparently Firefox is smart enough to figure it out. As a result, the file manager opens a window on behalf of firefox. The window will show a directory tree outside the sandbox, because the file manager itself runs outside the sandbox.

I start firefox with an empty home directory ("firefox --private firefox"), click on Open Profile, a window opens with my original home directory outside the sandbox - so far so good! Now, if audacious is installed, instead of the file manager window I get an audacious window popping up! The funny thing is audacious runs inside the sandbox, you can always check by clicking Open Files.

It is behaving like the file manager and audacious are triggered by the same dbus message, and somebody (maybe systemd?) decides to start audacious instead of passing the message to the file manager. And yes, when you use --net, the sandbox is not connected to dbus, so you'll see some changes in behaviour.

Anyway, I put in git some unrelated fixes to audacious profile.

@netblue30 commented on GitHub (Feb 21, 2017): I am getting the same thing, or something very close to what you have! > when trying to reach the Firefox profile directory from the about:support page in the browser, you will get an error because the .mozilla directory that the browser is now using with --private= is not supposed to be accessed in this way Actually when you press Open Profile in about:support, Firefox tries to communicate to an existing file manager. If you are running a desktop environment (as opposed to a simple window manager), the file manager is always there. It was started by default when the desktop manager was initialized. I suspect the communication is over dbus, but it could also also be over a regular Unix socket. It all depends on the file manager - apparently Firefox is smart enough to figure it out. As a result, the file manager opens a window on behalf of firefox. The window will show a directory tree outside the sandbox, because the file manager itself runs outside the sandbox. I start firefox with an empty home directory ("firefox --private firefox"), click on Open Profile, a window opens with my original home directory outside the sandbox - so far so good! Now, if audacious is installed, instead of the file manager window I get an audacious window popping up! The funny thing is audacious runs inside the sandbox, you can always check by clicking Open Files. It is behaving like the file manager and audacious are triggered by the same dbus message, and somebody (maybe systemd?) decides to start audacious instead of passing the message to the file manager. And yes, when you use --net, the sandbox is not connected to dbus, so you'll see some changes in behaviour. Anyway, I put in git some unrelated fixes to audacious profile.

gitea-mirror commented

2026-05-05 06:33:56 -06:00

Author

Owner

@acrobat1 commented on GitHub (Feb 27, 2017):

I can confirm that this unwanted instance of audacious that pops up is indeed running as a subprocess of the firefox firejail as pstree is showing:

audacious,26976,15767 /home/user/.mozilla/firefox/profile.default ├─{gdbus},26979,15767 ├─{audacious},26980,15767 ├─{audacious},26986,15767 ├─{audacious},26987,15767 └─{audacious},26988,15767

and that - by the looks of it - may have something to do with what dbus thinks needs to be done.

Also, I can reproduce this by simply placing a firefox profile in /tmp and then clicking about:support --> Open Directory : there's actually no need to use the --private argument in firejail, and it even happens if audacious has never been launched in the current desktop session.

Using --blacklist=/usr/bin/audacious in the firejail command line for firefox kinda mitigates this, because this weird issue won't happen and an instance of the file manager will open with the actual path to the firefox profile (as it should be) - however, a blacklist violation will still be logged:

blacklist violation - sandbox 18838, exe firefox, syscall access, path /usr/bin/audacious

@acrobat1 commented on GitHub (Feb 27, 2017): I can confirm that this unwanted instance of audacious that pops up is indeed running as a subprocess of the firefox firejail as pstree is showing: `audacious,26976,15767 /home/user/.mozilla/firefox/profile.default ├─{gdbus},26979,15767 ├─{audacious},26980,15767 ├─{audacious},26986,15767 ├─{audacious},26987,15767 └─{audacious},26988,15767` and that - by the looks of it - may have something to do with what dbus *thinks* needs to be done. Also, I can reproduce this by simply placing a firefox profile in /tmp and then clicking about:support --> Open Directory : there's actually no need to use the --private argument in firejail, and it even happens if audacious has **never** been launched in the current desktop session. Using **--blacklist=/usr/bin/audacious** in the firejail command line for firefox kinda mitigates this, because this weird issue won't happen and an instance of the file manager will open with the actual path to the firefox profile (*as it should be*) - however, a blacklist violation will still be logged: ` blacklist violation - sandbox 18838, exe firefox, syscall access, path /usr/bin/audacious`

gitea-mirror commented

2026-05-05 06:33:57 -06:00

Author

Owner

@acrobat1 commented on GitHub (Mar 7, 2017):

I'm also wondering if this message

(caja:166): EggSMClient-WARNING **: Failed to connect to the session manager: None of the authentication protocols specified are supported

which I can see in the terminal from which firefox is launched inside Firejail, may or may not have something to do with all this.

This message is printed when clicking about:support --> Open Directory in a "normal" instance of Firefox (=placed inside ~/.mozilla as opposed to /tmp or some firejail private directory), which as I've said above yields the expected result - meaning that in this case an instance of Caja (the default file manager for Debian with MATE desktop) opens with the actual path to the firefox profile in use.

So in this case -at least at first glance - everything would be working normally, if not for this strange message which apparently tells that something isn't right.

Please remember that in Debian stable Firejail still runs with that funny "as superuser" warning in the titlebar when used for GUI applications, maybe the warning I've reported has something to do with this?

@acrobat1 commented on GitHub (Mar 7, 2017): I'm also wondering if this message `(caja:166): EggSMClient-WARNING **: Failed to connect to the session manager: None of the authentication protocols specified are supported` which I can see in the terminal from which firefox is launched inside Firejail, may or may not have something to do with all this. This message is printed when clicking about:support --> Open Directory in a "normal" instance of Firefox (=placed inside ~/.mozilla as opposed to /tmp or some firejail private directory), which as I've said above yields the expected result - meaning that in this case an instance of Caja (the default file manager for Debian with MATE desktop) opens with the actual path to the firefox profile in use. So in this case -at least at first glance - everything would be working normally, if not for this strange message which apparently tells that something isn't right. Please remember that in Debian stable Firejail still runs with that funny **"as superuser"** warning in the titlebar when used for GUI applications, maybe the warning I've reported has something to do with this?

gitea-mirror commented

2026-05-05 06:33:58 -06:00

Author

Owner

@SYN-cook commented on GitHub (Mar 8, 2017):

I get the same behavior when I comment out whitelist ~/.config/mimeapps.list in whitelist-common.inc.

In order to figure out how to open a directory file, Firefox first checks if a default is defined in mimeapps.list. This file is absent, so Firefox looks in /usr/share/applications/mimeinfo.cache which programs claim to be able to handle datatype inode/directory.

In mimeinfo.cache, I have Audacious listed before Caja, which leads to the described behavior. Try to put Caja first, and everything should look much more regular.

@SYN-cook commented on GitHub (Mar 8, 2017): I get the same behavior when I comment out `whitelist ~/.config/mimeapps.list` in whitelist-common.inc. In order to figure out how to open a directory file, Firefox first checks if a default is defined in mimeapps.list. This file is absent, so Firefox looks in /usr/share/applications/mimeinfo.cache which programs claim to be able to handle datatype `inode/directory`. In mimeinfo.cache, I have Audacious listed _before_ Caja, which leads to the described behavior. Try to put Caja first, and everything should look much more regular.

gitea-mirror commented

2026-05-05 06:33:59 -06:00

Author

Owner

@acrobat1 commented on GitHub (Mar 28, 2017):

That's it ! Having commented out the entire whitelist-common.inc file in my firefox profile, I tried your workaround and it fixed this weird thing.

However: at the next reboot, audacious is back in /usr/share/applications/mimeinfo.cache before the file manager

inode/directory=audacious.desktop;caja-folder-handler.desktop;pcmanfm.desktop;

whilst the inode/directory entry is now missing altogether from .local/share/applications/mimeinfo.cache.

Which means that no application will now open the firefox profile directory, yet that's still much better than having audacious pop up unexpectedly.

So I'm not sure, is this an issue with firejail, or more likely something wrong in the way the system handles some applications/mimetypes?

Should I uncomment whitelist-common.inc in this firejail profile for firefox that I'm testing?

@acrobat1 commented on GitHub (Mar 28, 2017): That's it ! Having commented out the entire whitelist-common.inc file in my firefox profile, I tried your workaround and it fixed this weird thing. However: at the next reboot, audacious is back in /usr/share/applications/mimeinfo.cache before the file manager `inode/directory=audacious.desktop;caja-folder-handler.desktop;pcmanfm.desktop;` whilst the *inode/directory* entry is now missing altogether from .local/share/applications/mimeinfo.cache. Which means that no application will now open the firefox profile directory, yet that's still much better than having audacious pop up unexpectedly. So I'm not sure, is this an issue with firejail, or more likely something wrong in the way the system handles some applications/mimetypes? Should I uncomment whitelist-common.inc in this firejail profile for firefox that I'm testing?

gitea-mirror commented

2026-05-05 06:34:01 -06:00

Author

Owner

@SYN-cook commented on GitHub (Mar 28, 2017):

I'm sorry, the mimeinfo.cache mod was only for illustration. In order to permanently fix this, take your local mimeapps.list (the one you have in /home/user/config or /home/user/.local/share/applications), modify the inode/directory=... entry according to your preferences, and copy it to a place where it applies system-wide.

This differs between distributions, but places you could try are /etc/xdg, /usr/local/share/applications or /usr/share/applications.

@SYN-cook commented on GitHub (Mar 28, 2017): I'm sorry, the mimeinfo.cache mod was only for illustration. In order to permanently fix this, take your local mimeapps.list (the one you have in /home/user/config or /home/user/.local/share/applications), modify the `inode/directory=...` entry according to your preferences, and copy it to a place where it applies system-wide. This differs between distributions, but places you could try are /etc/xdg, /usr/local/share/applications or /usr/share/applications.

Rows
Columns

[GH-ISSUE #1090] Weird issue with Audacious and Firefox with --private=directory #747