mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #116] Unable to use ibus-daemon in firejail #75
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#75
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 @pyamsoft on GitHub (Nov 3, 2015).
Original GitHub issue: https://github.com/netblue30/firejail/issues/116
The ibus-daemon is used to change the languages on the system. For example, on my personal machine running Arch Linux 64bit using firejail 0.9.34-rc1, I use ibus to switch between English (US) input and Japanese inputs.
When not running in firejail, programs such as MousePad and rxvt-unicode for example will respect the current ibus language and type in either Japanese or English.
However, when running an application in firejail, because the ibus-daemon is not also running in the jail, and the jailed program has no way of talking to the rest of the processes running on the machine, programs such as Mousepad and Chromium do not properly switch inputs using the ibus-daemon.
Steps to reproduce:
ibus-daemon -drx@netblue30 commented on GitHub (Nov 3, 2015):
I'll look into it, thanks.
@netblue30 commented on GitHub (Nov 4, 2015):
Fixed!
@pyamsoft commented on GitHub (Nov 4, 2015):
This patch introduces a regression when using network namespaces with a bridge interface. Because of the new network ns, the iBus daemon will reject all forms on input.
This can be observed via the following:
br0--net=br0optionExcepted: Output of some kind
Result: iBus daemon rejects all input from the program, making it effectively impossible to run a network bridged namespace while using the ibus daemon.
A new issue can be opened in regards to this, or the current one can be reopened.
@netblue30 commented on GitHub (Nov 5, 2015):
I've disabled the previous fix if a network ns is created by the sandbox.
@ghost commented on GitHub (Nov 12, 2015):
beh, it doesn't work at all in Firefox.
You have to kill ibus to type anything.
"(firefox:1): IBUS-WARNING **: Events queue growing too big, will start to drop."
This seams to be a more general problem, with applications unable to communicate with the outside...
@netblue30 commented on GitHub (Nov 13, 2015):
Yes, I get the same thing if I have a network namespace configured. Without the net namespace it should work fine. I'll bring in a fix for network namespace.
The apps will not be able to communicate outside when a net namespace is configured. I'll have to proxy that traffic somehow.
@ioparaskev commented on GitHub (Jan 17, 2016):
Same issue exists in fedora too..
After that ibus is probably misbehaving since amixer cannot see any devices after this and gives an "Mixer attach default error: Connection refused" error.. This makes firejail unusable in my case unfortunately
Version: Fedora 23
How to reproduce:
firejail firefoxamixershows error"Mixer attach default error: Connection refused"@netblue30 commented on GitHub (Jan 18, 2016):
This looks more like a sound problem. Do you have PulseAudio installed, or only ALSA?
@ioparaskev commented on GitHub (Jan 21, 2016):
I have also pulseaudio and same happens with pulseaudio.. After the reproduce I'm losing control over the sound device.
sh -c "pactl set-sink-mute 0 false ; pactl set-sink-volume 1 -100%"@netblue30 commented on GitHub (Jan 21, 2016):
So, it is a sound problem, it has nothing to do with ibus. PulseAudio has a problem when running in a PID namespace. There is a workaround until they fix the problem. Look at "Known Problems" section here:
https://firejail.wordpress.com/support/
@ioparaskev commented on GitHub (Jan 21, 2016):
oh I see.. thanks and sorry for hijacking this
@netblue30 commented on GitHub (Jan 23, 2016):
No problem!
@ghost commented on GitHub (May 9, 2016):
Same in Ubuntu 16.04
@dfaerch commented on GitHub (Jun 25, 2016):
I wanted to try out firejail (0.9.40 on ubuntu 14.04), but I seem to be having the same issue. I did
but keyboard doesn't respond and i get errors in the console:
@biergaizi commented on GitHub (Oct 9, 2016):
Still no possible solutions? It basically disables any keyboard inputs on a iBus-based desktop, since English is also managed by iBus, and effectively made the great Firejail useless...
@folti commented on GitHub (Jan 10, 2017):
temporary workaround is to tell Gtk to use a different input module, by setting the GTK_IM_MODULE accordingly. For example:
don't have keyboard, while
does.
@netblue30 commented on GitHub (Jan 12, 2017):
Thanks for the info, I'll document it on the web site.
@anatoli26 commented on GitHub (Mar 25, 2017):
Hi, I just wanted to try Firejail on Ubuntu 16.04 stock with the latest Firefox 52.0.1 from xenial channel. The FJ version from the official channel (firejail/xenial 0.9.38.10-0ubuntu0.16.04.1 amd64) had a number of issues (especially with sound and broke it for other apps that were started before the FJ install), then I learned that this version is quite outdated and has a known issue with sound, so I purged it and installed a new one from this repo (0.9.45), but I get the same issue as other users here:
(firefox:7): IBUS-WARNING **: Unable to connect to ibus: Could not connect: Connection refusedThen, when trying to type anything, I get:
(firefox:7): IBUS-WARNING **: Events queue growing too big, will start to drop.Is there any solution to this problem?
UPDATE: tried more apps (rhythmbox, wire messenger, etc.), they all seem to have the same problem under FJ: IBUS-WARNING and no keyboard.
@netblue30 commented on GitHub (Mar 26, 2017):
I'll give it a try, thanks.
@pdo-smith commented on GitHub (May 10, 2017):
I have the same problem in Ubuntu 17.04
The fix given by folti (GTK_IM_MODULE=xim firejail opera) works.
@cwmke commented on GitHub (Aug 17, 2017):
I've been using Fedora lately without this issue happening. Tonight I installed the nvidia drivers and the problem started again. I don't have the issue with intel video drivers. It only seems to happen when I'm using nvidia.
@chiraag-nataraj commented on GitHub (Jun 7, 2018):
Is this still an issue and do the workarounds above not work?
@dfaerch commented on GitHub (Jun 12, 2018):
@chiraag-nataraj my issue has resolved itself over time. works-for-me
@graywolf commented on GitHub (Jul 5, 2018):
I still have the issue,
GTK_IM_MODULE=ibus firefoxdoes not work. I don't think this should be closed.@chiraag-nataraj commented on GitHub (Jul 8, 2018):
@graywolf Hmm, okay. Reopening. Maybe someone who uses ibus can help you debug (I used to, but switched over to
setxkbmap+emacsfor esoteric keyboards).@chiraag-nataraj commented on GitHub (Aug 6, 2018):
@graywolf, have you tried the workarounds on this thread?
@graywolf commented on GitHub (Aug 14, 2018):
@chiraag-nataraj I've tried (and it seems to work), however guys over at ibus keep telling me that it's wrong thing to do https://github.com/ibus/ibus/issues/2020#issuecomment-409171856
@chiraag-nataraj commented on GitHub (Aug 14, 2018):
@graywolf The way I look at it is: If it works, don't worry about it 😂 Seriously, though...unless there are security implications, this is probably okay. If it stops working, we'll figure something out then 😂
@graywolf commented on GitHub (Aug 14, 2018):
I guess... 🍡
@chiraag-nataraj commented on GitHub (Aug 22, 2018):
So if the workarounds here are working (ibus developers' opinions notwithstanding), I'm going to go ahead and close the issue.
@chiraag-nataraj commented on GitHub (Aug 22, 2018):
On second thought, re-opening, since this is still an issue that should be debugged.
@xelxebar commented on GitHub (Nov 4, 2018):
For whatever it's worth the proposed
*_IM_MODULEworkaround doesn't fix the issue for me, though I'm running qutebrowser instead of firefox.@mhva commented on GitHub (Feb 4, 2019):
Disclaimer: I don't use firejail, but I'm almost positive that this issue is related to the fact that ibus-daemon uses an abstract unix socket for IPC by default. This socket is invisible to firejail sandbox if it resides in a separate network namespace.
It should be possible to circumvent this issue in the current master branch of ibus by requesting it to use named socket for IPC. This can be done by passing
--address=unix:path=<somedir>/<somefile>to ibus-daemon and making sure that<somedir>and$HOME/.config/ibusare both visible in sandbox. The latter dir contains ibus-daemon socket address, which is needed for ibus clients to be able to find where they should connect.@biergaizi commented on GitHub (Feb 4, 2019):
Awesome! Having the capability to use an alternative IPC socket should definitely solve the problem.
@chiraag-nataraj commented on GitHub (May 20, 2019):
Given the workaround @mhva suggested, do people still have this issue?
@chiraag-nataraj commented on GitHub (May 21, 2019):
I'm going to go ahead and close this for now. If anyone affected is still running into this, please feel free to re-open!
@SailReal commented on GitHub (May 21, 2020):
I just started using firejail, what an awesome piece of software, thank you all :)
Nearly everything works out of the box but I just stumbled over this issue using Ubuntu 20.04 and the Signal-Desktop client. On my device it can only be started with
GTK_IM_MODULE=xim, otherwise you can't enter anything using my keyboard.@ghost commented on GitHub (May 22, 2020):
@SailReal Glad to hear you're enjoying firejail. As for the environment variable workaround, you can put that into a
signal-desktop.localfile. If you don't have one yet, you will have to create one manually. Either use /etc/firejail/signal-desktop.local (affects all users on your machine) or ${HOME}/.config/firejail/signal-desktop.local (affects your user only). Add the below to that file:@overchu commented on GitHub (Dec 18, 2020):
Where can you pass these argruments to ibus? I couldn't figure out who is starting ibus in the first place.
systemdseems not to start itsystemd --userBut anyway, if I stop ibus-daemon and start it manually with the given options, than I got an error that the address is already in use.
So it seems that even if I find out where ibus is started in will not work anyway.
I am running Fedora 33 with Gnome 3, X, and ibus 1.5.23
@ghost commented on GitHub (Dec 18, 2020):
On Arch Linux the ibus package installs
/usr/share/dbus-1/services/org.freedesktop.IBus.service:If memory serves you can place an override in /etc/dbus-1/services/org.freedesktop.IBus.service with your desired Exec= command.
Note: As of Jul 2020, Firejail introduced DBus filtering. It is now possible to use the --dbus-user.own=org.freedesktop.IBus parameter to let Firefox access IBus.
@overchu commented on GitHub (Dec 19, 2020):
Thank you for the idea of just checking what hte package installs. You are right.
But I don't see this
.service-file linked anywhere, so I don't think this is what actually gets used:Both yield empty results.
And no mentioning of ibus in /etc/dbus-1/ either, no results for:
@overchu commented on GitHub (Dec 19, 2020):
Sorry, I forgot to mention that I tried this solution unsuccessfully:
I even consider a security bug because it spits out a working firefox (with ibus) that is not sandboxed which is not what you expect if you run
firejail.Above, this might be the most interesting line:
@rusty-snake commented on GitHub (Dec 19, 2020):
It's not a systemd unit. It's a D-Bus service (look at the
[D-BUS Service]line in it).D-Bus configuration is located at
/usr/share/dbus-1(distributions defaults) and/etc/dbus-1(user/admin overrides).--dbus-user.talk=org.freedesktop.IBusshould be enough.@rusty-snake commented on GitHub (Dec 19, 2020):
FWIW: Fcitx works we allowing the portal, see #3732.
@graywolf commented on GitHub (Nov 1, 2021):
The
ximworkaround stopped working for me on firefox 93.0. Should this be re-opened?@martinetd commented on GitHub (Dec 12, 2021):
I don't know about the xim workaround not working (I've never had input stuck because of ibus in default configuration), but the 'solution' that had been accepted years ago is nothing but a workaround that disables ibus, it's not a way of using ibus.
I've spent quite a bit of time on this, here's my take:
$HOME/.config/ibus/bus/<machineid>-<hostname>-<display>(ibus_get_socket_path()) to guess the ibus socket. While addingwhitelist ${HOME}/.config/ibusto the profile lets ibus load this file, ibus tries to check if the socket is valid by sending a signal (kill(0) to the pid defined in that file, and that doesn't work with our PID namespace, so giving access to that file is useless unless we could share the pid namespace, which is not possible https://github.com/netblue30/firejail/issues/892IBUS_ADDRESSdirectly in the environment (preload that file before starting firejail), which will skip the PID check.--address=unix:dir=/path/to/somedirand whitelist that directory to allow firefox to connect to it. Note ibus allows unix:path=/path/to/sock, but that doesn't work right now, see https://github.com/ibus/ibus/issues/2363dbus-user.talk org.freedesktop.IBusis also needed as suggested. Ther'e's also aorg.freedesktop.portal.IBusbut I didn't find this to be required.Ultimately my conf is as follow (using unix socket in ~/.cache/ibus)
@rusty-snake commented on GitHub (Jan 8, 2022):
seems to work too
@scottslowe commented on GitHub (May 25, 2022):
Confirming that @rusty-snake's workaround from Jan 8 2022 works for me on a newly-upgraded Fedora 36 system (to fix keyboard input for Thunderbird).
@martinetd commented on GitHub (Sep 8, 2022):
Follow up half a year later: turns out my system just doesn't start ibus-portal, running it manually and asking gtk to use it seems to be easier to handle than my old workaround so switched to that as well.
Thanks @rusty-snake !
@hmm5 commented on GitHub (Mar 31, 2023):
GTK_IM_MODULE=xim, doesn't seem to work anymore with the newest ibus version 1.5.28.