[GH-ISSUE #1718] Hexchat links do not open in chromium #1160

Closed
opened 2026-05-05 07:33:54 -06:00 by gitea-mirror · 9 comments
Owner

Originally created by @carbolymer on GitHub (Jan 8, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1718

Steps to reproduce

  1. start hexchat using firejail
firejail hexchat
  1. Invoke command in Hexchat:
/url google.com
  1. Nothing happens

Fix:

  1. Create ~/.config/firejail/hexchat.profile with the following content:
noblacklist ${HOME}/.config/chromium

include /etc/firejail/hexchat.profile

Somehow, hexchat tries to access ~/.config/chromium directory 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.

Originally created by @carbolymer on GitHub (Jan 8, 2018). Original GitHub issue: https://github.com/netblue30/firejail/issues/1718 ## Steps to reproduce 1. start hexchat using firejail ``` firejail hexchat ``` 2. Invoke command in Hexchat: ``` /url google.com ``` 3. Nothing happens ## ~~Fix:~~ 1. ~~Create~~ ~~`~/.config/firejail/hexchat.profile`~~ ~~with the following content:~~ ``` noblacklist ${HOME}/.config/chromium include /etc/firejail/hexchat.profile ``` ~~Somehow, hexchat tries to access `~/.config/chromium` directory 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.
gitea-mirror 2026-05-05 07:33:55 -06:00
Author
Owner

@chiraag-nataraj commented on GitHub (Jan 8, 2018):

I believe this is related to the fact that the hexchat profile has a private-bin which does not include chromium. I'm not sure why not blacklisting ~/.config/chromium helps though.

<!-- gh-comment-id:356102282 --> @chiraag-nataraj commented on GitHub (Jan 8, 2018): I believe this is related to the fact that the `hexchat` profile has a `private-bin` which does not include `chromium`. I'm not sure why not blacklisting `~/.config/chromium` helps though.
Author
Owner

@carbolymer commented on GitHub (Jan 13, 2018):

Weird. After last kernel update to 4.14.13-1-ARCH my workaround stopped working. Now to enable links opening in hexchat I have to edit /etc/firejail/hexchat.profile:

  1. change caps.drop all to caps.keep sys_chroot,sys_admin
  2. disable nonewprivs, noroot, protocol unix,inet,inet6, seccomp, tracelog
  3. add chromium to private-bin as @chiraag-nataraj suggested

...but this bypasses a lot of security settings. Any ideas why chromium is not opening from hexchat?

<!-- gh-comment-id:357438434 --> @carbolymer commented on GitHub (Jan 13, 2018): Weird. After last kernel update to `4.14.13-1-ARCH` my workaround stopped working. Now to enable links opening in hexchat I have to edit `/etc/firejail/hexchat.profile`: 1. change `caps.drop all` to `caps.keep sys_chroot,sys_admin` 1. disable `nonewprivs`, `noroot`, `protocol unix,inet,inet6`, `seccomp`, `tracelog` 1. add `chromium` to `private-bin` as @chiraag-nataraj suggested ...but this bypasses a lot of security settings. Any ideas why chromium is not opening from hexchat?
Author
Owner

@chiraag-nataraj commented on GitHub (Jan 13, 2018):

If you run a firejail --list, you'll probably see that chromium was started inside of the hexchat profile, which is why you need to disable all that stuff (chromium has its own sandbox and stuff). Does this happen if you keep chromium running (in its own sandbox) and then open hexchat? That is:

  1. Open Chromium within its own jail.
  2. Open Hexchat within its own jail (use the default profile, except you'll probably have to add chromium to the private-bin).
  3. Try opening a link.

My suspicion is that if you're not already running Chromium, it starts its own instance inside the hexchat jail, leading to the behavior (and profile changes) you're describing.

<!-- gh-comment-id:357440589 --> @chiraag-nataraj commented on GitHub (Jan 13, 2018): If you run a `firejail --list`, you'll probably see that `chromium` was started _inside of the hexchat profile_, which is why you need to disable all that stuff (`chromium` has its own sandbox and stuff). Does this happen if you keep `chromium` running (in its own sandbox) and then open hexchat? That is: 1. Open Chromium within its own jail. 2. Open Hexchat within its own jail (use the default profile, except you'll probably have to add `chromium` to the `private-bin`). 3. Try opening a link. My suspicion is that if you're not already running Chromium, it starts its own instance inside the `hexchat` jail, leading to the behavior (and profile changes) you're describing.
Author
Owner

@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.

<!-- gh-comment-id:357440696 --> @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" :wink: Since I'm on Debian, I could probably do some convoluted thing with `xdg-open`, but...meh.
Author
Owner

@carbolymer commented on GitHub (Jan 13, 2018):

Does this happen if you keep chromium running (in its own sandbox) and then open hexchat?

Yes.

Is there a way to make chromium run in its own sandbox from hexchat?

<!-- gh-comment-id:357441131 --> @carbolymer commented on GitHub (Jan 13, 2018): > Does this happen if you keep chromium running (in its own sandbox) and then open hexchat? Yes. Is there a way to make chromium run in its own sandbox from hexchat?
Author
Owner

@chiraag-nataraj commented on GitHub (Jan 13, 2018):

Yes.

Huh, weird.

Is there a way to make chromium run in its own sandbox from hexchat?

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).

<!-- gh-comment-id:357441661 --> @chiraag-nataraj commented on GitHub (Jan 13, 2018): > Yes. Huh, weird. > Is there a way to make chromium run in its own sandbox from hexchat? 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).
Author
Owner

@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.

<!-- gh-comment-id:405133186 --> @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.
Author
Owner

@carbolymer commented on GitHub (Jul 17, 2018):

Yes, I still have this issue. I've also given up and I am copy-pasting it.

<!-- gh-comment-id:405516987 --> @carbolymer commented on GitHub (Jul 17, 2018): Yes, I still have this issue. I've also given up and I am copy-pasting it.
Author
Owner

@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:

  1. Drastically reduce security for profiles which need to open stuff in Chrome.
  2. Copy links and paste them in an already-open Chrome window (running in its own sandbox).

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.

<!-- gh-comment-id:406819438 --> @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: 1. Drastically reduce security for profiles which need to open stuff in Chrome. 2. Copy links and paste them in an already-open Chrome window (running in its own sandbox). 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.
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#1160
No description provided.