mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #3112] Pavucontrol error while closing #1952
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1952
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
This does not happen if pavucontrol is run outside of firejail.
Firejail version: 0.9.62
Pavucontrol version: 4.0
@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.@rusty-snake commented on GitHub (Jan 3, 2020):
Suggested fix (commenting and adding a note):
For the other collaborators,
tracelog@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
GTKapplications (if that makes sense). Having encountered a similar issue with artha yesterday seems to point in that direction.@rusty-snake commented on GitHub (Jan 3, 2020):
no3dcan 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 needsmemfd_create.@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 renamingwhitelisted paths.@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?
@rusty-snake commented on GitHub (Jan 3, 2020):
@glitsj16 ^
@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 ^.