mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1718] Hexchat links do not open in chromium #1160
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#1160
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 @carbolymer on GitHub (Jan 8, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1718
Steps to reproduce
Fix:Create~/.config/firejail/hexchat.profilewith the following content:Somehow, hexchat tries to access~/.config/chromiumdirectory when opening URLs. Can we add some rule (I am not sure if my solution is the secure one) for handling such cases?UPDATE: This workaround stopped working.
@chiraag-nataraj commented on GitHub (Jan 8, 2018):
I believe this is related to the fact that the
hexchatprofile has aprivate-binwhich does not includechromium. I'm not sure why not blacklisting~/.config/chromiumhelps though.@carbolymer commented on GitHub (Jan 13, 2018):
Weird. After last kernel update to
4.14.13-1-ARCHmy workaround stopped working. Now to enable links opening in hexchat I have to edit/etc/firejail/hexchat.profile:caps.drop alltocaps.keep sys_chroot,sys_adminnonewprivs,noroot,protocol unix,inet,inet6,seccomp,tracelogchromiumtoprivate-binas @chiraag-nataraj suggested...but this bypasses a lot of security settings. Any ideas why chromium is not opening from hexchat?
@chiraag-nataraj commented on GitHub (Jan 13, 2018):
If you run a
firejail --list, you'll probably see thatchromiumwas started inside of the hexchat profile, which is why you need to disable all that stuff (chromiumhas its own sandbox and stuff). Does this happen if you keepchromiumrunning (in its own sandbox) and then open hexchat? That is:chromiumto theprivate-bin).My suspicion is that if you're not already running Chromium, it starts its own instance inside the
hexchatjail, leading to the behavior (and profile changes) you're describing.@chiraag-nataraj commented on GitHub (Jan 13, 2018):
Also, for what it's worth, I've given up on allowing apps to talk to each other. If I want to open a link, I copy-paste it into my browser window. This has the added benefit of making me check the URL before hitting "Go" 😉 Since I'm on Debian, I could probably do some convoluted thing with
xdg-open, but...meh.@carbolymer commented on GitHub (Jan 13, 2018):
Yes.
Is there a way to make chromium run in its own sandbox from hexchat?
@chiraag-nataraj commented on GitHub (Jan 13, 2018):
Huh, weird.
Nope - not yet. I forget where, but there's an open bug report about this (tried a cursory search but couldn't find it... @netblue30).
@chiraag-nataraj commented on GitHub (Jul 16, 2018):
@carbolymer Do you still have this issue? Most likely, chromium doesn't know how to talk to an already-running instance and thus you're experiencing this problem. Personally, as I said above, I've given up on having apps talk to each other. If there's a link I want to open, I copy-paste it. Simple and keeps the boundaries separate.
@carbolymer commented on GitHub (Jul 17, 2018):
Yes, I still have this issue. I've also given up and I am copy-pasting it.
@chiraag-nataraj commented on GitHub (Jul 21, 2018):
@carbolymer Okay. Yeah, it's not ideal, but this is what happens when every program assumes it can talk with other programs with absolutely no security boundaries - as soon as you put security boundaries in place, things break. I don't have this problem with firefox since (I think) it uses something in the profile directory to determine if firefox is already running - I assume chromium uses some other method which breaks as soon as you install PID namespaces or some other basic isolation techniques used by firejail.
The two options you have are:
Personally, (2) is the clear winner, but depending on what your priorities are, you may end up going with (1). Since we don't really have any way to fix this without drastically reducing security for many profiles, I'm going to go ahead and close this.