mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #2889] transmission-remote-gtk libcanberra issue - fails to start #1806
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#1806
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 @ilikenwf on GitHub (Aug 4, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2889
I'm using transmission-remote-gtk 1.4.1
@ilikenwf commented on GitHub (Aug 4, 2019):
...it does start without using firejail.
@Fred-Barclay commented on GitHub (Aug 4, 2019):
Hi @ilikenwf
What version of firejail and linux distro are you using?
Can you open the file
/etc/firejail/transmission-remote.profileand comment out the linememory-deny-write-execute(put a#at the beginning of the line). Then save it and try to run transmission-remote-gtk with firejail again.Cheers!
Fred
@ghost commented on GitHub (Aug 5, 2019):
@ilikenwf Depending on firejail version and OS used this part of the issue might be caused by using
private-libwithout any further specifications in the profile or by simply not having the mentioned GTK module installed on your system. On Arch it is part of thelibcanberrapackage but you can check this with your OS's native package manager tools. I'm guessing this issue can be easily fixed as soon as we get more info from your side on what @Fred-Barclay asked above. Thanks for reporting this.@ilikenwf commented on GitHub (Aug 5, 2019):
I'm using arch and have both canberra packages installed; I'm also using the git version of firejail.
@ilikenwf commented on GitHub (Aug 5, 2019):
Commenting out the private-lib and memory-deny-write-execute directives results in only this:
@Fred-Barclay commented on GitHub (Aug 5, 2019):
@ilikenwf With
private-libstill commented out, can you try addingunixto theprotocolline?E.g.
EDIT: second inet is inet6
@Fred-Barclay commented on GitHub (Aug 5, 2019):
Also (with
protocol unix,inet,inet6) can you try out the following private-lib?@ilikenwf commented on GitHub (Aug 5, 2019):
Adding unix to the protocol line helped in that the application now runs, however it seems to be
unable to read it's profile in .config or wherver transmission-remote stores settings.
The private-lib settings cause it to break again...
Those settings appear to be in ~/.config/transmission-remote-gtk
Beyond that it is reading settings with the mkdir and whitelist in place, however it can't resolve my transmission host's domain now.
@rusty-snake commented on GitHub (Aug 5, 2019):
@ilikenwf so the following
transmission-remote-gtk.profileworks?not sure about
ignore mdweand${HOME}/.config/transmissionTry
--ignore=private-etcif that fix it try--private-etc=resolv.conf.@ghost commented on GitHub (Aug 5, 2019):
IMHO we should redo the profile and redirect to
transmission-gtk.profileinstead. That should solve all encountered issues by @ilikenwf in a more elegant and maintainable way. Just my two cents.@rusty-snake commented on GitHub (Aug 5, 2019):
Or turn the redirect
=> transmission-remote.profile include transmission-remote-gtk.profile and add some restrictions.
@ilikenwf commented on GitHub (Aug 5, 2019):
The modifications I mentioned to transmission-remote.profile and the above do work to run the application, however it is not able to access the network for some reason.
@rusty-snake commented on GitHub (Aug 6, 2019):
internet or your LAN?
I assume that
firejail --noprofile transmission-remote-gtkworks.Can you try
firejail --ignore=eth --ignore=netfilter --ignore=protocol --ignore=net --ignore="net none" --ignore=private-etc --ignore=nodbus transmission-remote-gtk. And if it works, try to find out whichignoreis needed.@ilikenwf commented on GitHub (Aug 6, 2019):
firejail --noprofile transmission-remote-gtkdoes indeed work as expected.@ilikenwf commented on GitHub (Aug 6, 2019):
Ok, so it seems these are the ones breaking it, as it runs fine this way:
firejail --ignore=protocol --ignore=private-lib --ignore=private-etc transmission-remote-gtkAlong with these profiles:
https://gist.github.com/ilikenwf/f265644a87788d0a698c9a5e8cbc1e2a
@rusty-snake commented on GitHub (Aug 6, 2019):
@ilikenwf transmisson has a very restrictiv private-etc, can you try with:
--private-etc=ca-certificates,ssl,pki,crypto-policies,nsswitch.conf,resolv.conf,hosts,host.conf,hostname,protocols,services,rpcAnd maybe also:
--private-etc=alternatives,ld.so.cache,ld.so.conf,ld.so.conf.d,ld.so.preload,locale,locale.alias,locale.conf,localtime,mime.types,xdg,dconf,gconf,gtk-2.0,gtk-3.0@ilikenwf commented on GitHub (Aug 7, 2019):
After playing with those private-etc settings, I find this is the minimum required to work with the aforementioned/gisted profiles:
firejail --ignore=protocol --private-etc=resolv.conf,hosts,hostname transmission-remote-gtk@ilikenwf commented on GitHub (Aug 7, 2019):
Ok, so after all that is rolled into the profiles I end up with this so far:
So we're really just down to the private lib ignore line being the only ignore rule now...
@ghost commented on GitHub (Aug 21, 2019):
I've gone ahead and pushed refactored transmission profiles. Re-opening this to get input from the OP, @ilikenwf.
@ghost commented on GitHub (Aug 28, 2019):
@ilikenwf I'm closing this as it should be fixed now. Feel free to reopen when needed.