Hexchat links do not open in chromium

[carbolymer]

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.

[chiraag-nataraj]

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.

[carbolymer]

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?

[chiraag-nataraj]

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.

[chiraag-nataraj]

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]

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?

[chiraag-nataraj]

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

[chiraag-nataraj]

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

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

[chiraag-nataraj]

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