[GH-ISSUE #3112] Pavucontrol error while closing #1952

Closed
opened 2026-05-05 08:37:05 -06:00 by gitea-mirror · 8 comments
Owner

Originally created by @setpill on GitHub (Jan 3, 2020).
Original GitHub issue: https://github.com/netblue30/firejail/issues/3112

When closing pavucontrol, it shows an error message saying

Error writing config file %s/home/[user]/.config/pavucontrol.ini: Bad state

This does not happen if pavucontrol is run outside of firejail.

Firejail version: 0.9.62
Pavucontrol version: 4.0

Originally created by @setpill on GitHub (Jan 3, 2020). Original GitHub issue: https://github.com/netblue30/firejail/issues/3112 When closing pavucontrol, it shows an error message saying > Error writing config file %s/home/[user]/.config/pavucontrol.ini: Bad state This does not happen if pavucontrol is run outside of firejail. Firejail version: 0.9.62 Pavucontrol version: 4.0
gitea-mirror 2026-05-05 08:37:05 -06:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

@rusty-snake commented on GitHub (Jan 3, 2020):

pavucontrol writes first a file ~/.config/pavucontrol.ini.XXXXXX (where XXXXXX is random) and then renames this file. Currently this isn't supported in firejails whitelist implementation.

<!-- gh-comment-id:570588090 --> @rusty-snake commented on GitHub (Jan 3, 2020): pavucontrol writes first a file `~/.config/pavucontrol.ini.XXXXXX` (where XXXXXX is random) and then renames this file. Currently this isn't supported in firejails whitelist implementation.
Author
Owner

@rusty-snake commented on GitHub (Jan 3, 2020):

Suggested fix (commenting and adding a note):

@@ -16,11 +16,11 @@ include disable-passwdmgr.inc
 include disable-programs.inc
 include disable-xdg.inc
 
-mkfile ${HOME}/.config/pavucontrol.ini
-whitelist ${HOME}/.config/pavucontrol.ini
+#mkfile ${HOME}/.config/pavucontrol.ini
+#whitelist ${HOME}/.config/pavucontrol.ini
 whitelist /usr/share/pavucontrol
 whitelist /usr/share/pavucontrol-qt
-include whitelist-common.inc
+#include whitelist-common.inc
 include whitelist-usr-share-common.inc

whitelisting in ${HOME} is broken, see #3112


For the other collaborators,

  1. Should it have internet (avahi) access by default or should we do this opt-in?
  2. We can add tracelog
  3. mdwe can be removed.
<!-- gh-comment-id:570588357 --> @rusty-snake commented on GitHub (Jan 3, 2020): Suggested fix (commenting and adding a note): ```diff @@ -16,11 +16,11 @@ include disable-passwdmgr.inc include disable-programs.inc include disable-xdg.inc -mkfile ${HOME}/.config/pavucontrol.ini -whitelist ${HOME}/.config/pavucontrol.ini +#mkfile ${HOME}/.config/pavucontrol.ini +#whitelist ${HOME}/.config/pavucontrol.ini whitelist /usr/share/pavucontrol whitelist /usr/share/pavucontrol-qt -include whitelist-common.inc +#include whitelist-common.inc include whitelist-usr-share-common.inc ``` > whitelisting in ${HOME} is broken, see #3112 --- For the other collaborators, 1. Should it have internet (avahi) access by default or should we do this opt-in? 2. We can add `tracelog` 3. mdwe can be removed.
Author
Owner

@ghost commented on GitHub (Jan 3, 2020):

It dawned on me that I completely missed the error message when originally creating/contributing the pavucontrol profile, or at least can't remember seeing it. I've been using the QT5 version of pavucontrol available on Arch Linux with much joy, firejail and otherwise. That particular version does not show the error dialog on shutdown and shows no issues with whitelisting in ${HOME} as far as I can determine.

So although @rusty-snake's suggested fix does work, it makes me doubt that whitelisting in ${HOME} is in fact completely broken. Perhaps it is only broken for GTK applications (if that makes sense). Having encountered a similar issue with artha yesterday seems to point in that direction.

  1. Should it have internet (avahi) access by default or should we do this opt-in?
    Always difficult to decide for everybody else. We should at least point users to more context via a comment so they can make their own informed decision.
  1. We can add tracelog
    Works.
  1. mdwe can be removed.
    mdwe works for me on Xorg, breaks on Wayland.
<!-- gh-comment-id:570630497 --> @ghost commented on GitHub (Jan 3, 2020): It dawned on me that I completely missed the error message when originally creating/contributing the _pavucontrol_ profile, or at least can't remember seeing it. I've been using the [QT5 version](https://www.archlinux.org/packages/community/x86_64/pavucontrol-qt/) of pavucontrol available on Arch Linux with much joy, firejail and otherwise. That particular version does **not** show the error dialog on shutdown and shows **no** issues with whitelisting in ${HOME} as far as I can determine. So although @rusty-snake's suggested fix does work, it makes me doubt that whitelisting in ${HOME} is in fact completely broken. Perhaps it is _only_ broken for `GTK` applications (if that makes sense). Having encountered a [similar issue](https://github.com/netblue30/firejail/commit/3f94dd1d4769f413d5390198b2bba14e821f03bb) with artha yesterday seems to point in that direction. > 1. Should it have internet (avahi) access by default or should we do this opt-in? Always difficult to decide for everybody else. We should at least point users to more context via a comment so they can make their own informed decision. > 2. We can add tracelog Works. > 3. mdwe can be removed. mdwe works for me on Xorg, breaks on Wayland.
Author
Owner

@rusty-snake commented on GitHub (Jan 3, 2020):

  1. right, what about default support and a note to disable if to required.
  2. That's new for me, I know that no3d can be special on Wayland. That mdwe can be break on Wayland and work on Xorg is new for me. However, if it works with Xorg we should leave it and update the comment. Looks like the GTK Wayland implementation needs memfd_create.
<!-- gh-comment-id:570632783 --> @rusty-snake commented on GitHub (Jan 3, 2020): 1. right, what about default support and a note to disable if to required. 3. That's new for me, I know that `no3d` can be special on Wayland. That mdwe can be break on Wayland and work on Xorg is new for me. However, if it works with Xorg we should leave it and update the comment. Looks like the GTK Wayland implementation needs `memfd_create`.
Author
Owner

@rusty-snake commented on GitHub (Jan 3, 2020):

@glitsj16 the "whitelisting in ${HOME} is broken, see #3112" is the suggested comment which is missing in the diff. It is only true for pavouconrol (and a few other) since whitelisting can't glob (atm) and probably never supports renaming whitelisted paths.

<!-- gh-comment-id:570633892 --> @rusty-snake commented on GitHub (Jan 3, 2020): @glitsj16 the "whitelisting in ${HOME} is broken, see #3112" is the suggested comment which is missing in the diff. It is only true for pavouconrol (and a few other) since `whitelist`ing can't glob (atm) and probably never supports renaming `whitelist`ed paths.
Author
Owner

@ghost commented on GitHub (Jan 3, 2020):

@rusty-snake Oh, thanks for pointing that out, I read that differently.
Personally I'm ok with enabling network access by default and adding a how-to-disable comment. Same goes for mdwe. Will you be making the PR?

<!-- gh-comment-id:570641688 --> @ghost commented on GitHub (Jan 3, 2020): @rusty-snake Oh, thanks for pointing that out, I read that differently. Personally I'm ok with enabling _network_ access by default and adding a how-to-disable comment. Same goes for _mdwe_. Will you be making the PR?
Author
Owner

@rusty-snake commented on GitHub (Jan 3, 2020):

@glitsj16 ^

<!-- gh-comment-id:570647989 --> @rusty-snake commented on GitHub (Jan 3, 2020): @glitsj16 ^
Author
Owner

@ghost commented on GitHub (Jan 3, 2020):

@rusty-snake Looks fine 👍 . I'd say add it. If other people have input we can always deal with it later. I changed artha.profile accordingly ^.

<!-- gh-comment-id:570655806 --> @ghost commented on GitHub (Jan 3, 2020): @rusty-snake Looks fine :+1: . I'd say add it. If other people have input we can always deal with it later. I changed artha.profile accordingly ^.
Sign in to join this conversation.
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#1952
No description provided.