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 -drxI'll look into it, thanks.
Fixed!
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=br0 optionExcepted: 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.
I've disabled the previous fix if a network ns is created by the sandbox.
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...
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.
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 firefoxamixer shows error "Mixer attach default error: Connection refused"This looks more like a sound problem. Do you have PulseAudio installed, or only ALSA?
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%"
shm_open() failed: No such file or directory
Connection failure: Protocol error
shm_open() failed: No such file or directory
Connection failure: Protocol error
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:
oh I see.. thanks and sorry for hijacking this
No problem!
Same in Ubuntu 16.04
I wanted to try out firejail (0.9.40 on ubuntu 14.04), but I seem to be having the same issue. I did
$ firejail google-chrome
but keyboard doesn't respond and i get errors in the console:
(google-chrome:2): IBUS-WARNING **: Unable to connect to ibus: Could not connect: Connection refused
(google-chrome:2): IBUS-WARNING **: Events queue growing too big, will start to drop.
(google-chrome:2): IBUS-WARNING **: Events queue growing too big, will start to drop.
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...
temporary workaround is to tell Gtk to use a different input module, by setting the GTK_IM_MODULE accordingly. For example:
firejail opera
don't have keyboard, while
GTK_IM_MODULE=xim firejail opera
does.
Thanks for the info, I'll document it on the web site.
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 refused
Then, 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.
I'll give it a try, thanks.
I have the same problem in Ubuntu 17.04
The fix given by folti (GTK_IM_MODULE=xim firejail opera) works.
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.
Is this still an issue and do the workarounds above not work?
@chiraag-nataraj my issue has resolved itself over time. works-for-me
I still have the issue, GTK_IM_MODULE=ibus firefox does not work. I don't think this should be closed.
@graywolf Hmm, okay. Reopening. Maybe someone who uses ibus can help you debug (I used to, but switched over to setxkbmap + emacs for esoteric keyboards).
@graywolf, have you tried the workarounds on this thread?
@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
@graywolf The way I look at it is: If it works, don't worry about it :joy: Seriously, though...unless there are security implications, this is probably okay. If it stops working, we'll figure something out then :joy:
I guess... :dango:
So if the workarounds here _are_ working (ibus developers' opinions notwithstanding), I'm going to go ahead and close the issue.
On second thought, re-opening, since this is still an issue that should be debugged.
For whatever it's worth the proposed *_IM_MODULE workaround doesn't fix the issue for me, though I'm running qutebrowser instead of firefox.
$ firejail --version
firejail version 0.9.56
Compile time support:
- AppArmor support is enabled
- AppImage support is enabled
- chroot support is enabled
- file and directory whitelisting support is enabled
- file transfer support is enabled
- networking support is enabled
- overlayfs support is enabled
- private-home support is enabled
- seccomp-bpf support is enabled
- user namespace support is enabled
- X11 sandboxing support is enabled
$ ibus version
1.5.1.19
$ qutebrowser --version
qutebrowser v1.5.2
Git commit:
Backend: QtWebEngine (Chromium 61.0.3163.140)
CPython: 3.6.7
Qt: 5.10.1
PyQt: 5.10.1
sip: 4.19.8
colorama: no
pypeg2: 2.15
jinja2: 2.10
pygments: 2.2.0
yaml: 3.13
cssutils: no
attr: 18.2.0
PyQt5.QtWebEngineWidgets: yes
PyQt5.QtWebKitWidgets: no
pdf.js: no
sqlite: 3.25.2
QtNetwork SSL: LibreSSL 2.7.4
...
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/ibus are 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.
Awesome! Having the capability to use an alternative IPC socket should definitely solve the problem.
Given the workaround @mhva suggested, do people still have this issue?
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!
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.
@SailReal Glad to hear you're enjoying firejail. As for the environment variable workaround, you can put that into a signal-desktop.local file. 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:
env GTK_IM_MODULE=xim
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.
Where can you pass these argruments to ibus? I couldn't figure out who is starting ibus in the first place.
systemd seems 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.
$ ps aux | grep ibus-
alex 33084 2.2 0.0 815460 13488 pts/4 Sl 13:44 0:00 ibus-daemon --replace --panel disable --xim
alex 33105 0.0 0.0 449324 7396 pts/4 Sl 13:44 0:00 /usr/libexec/ibus-dconf
alex 33106 4.0 0.1 483180 28636 pts/4 Sl 13:44 0:01 /usr/libexec/ibus-extension-gtk3
alex 33108 0.1 0.1 404168 22388 pts/4 Sl 13:44 0:00 /usr/libexec/ibus-x11 --kill-daemon
alex 33116 0.0 0.0 449092 7292 ? Ssl 13:44 0:00 /usr/libexec/ibus-portal
alex 33128 0.5 0.0 375336 7148 pts/4 Sl 13:44 0:00 /usr/libexec/ibus-engine-simple
alex 33207 0.0 0.0 221588 852 pts/4 S+ 13:45 0:00 grep --color=auto ibus-
$ kill 33084 # kill ibus-daemon
$ ibus-daemon --replace --panel disable --xim --address=unix:path=/home/alex/.cache/alex-ibus/ibus-address/test --verbose
(ibus-daemon:35008): IBUS-ERROR **: 13:57:37.755: g_dbus_server_new_sync() is failed with address unix:path=/home/alex/.cache/alex-ibus/ibus-address/test and guid 30d04cbb95ff4a29d0b02d835fdc44d1: Error binding to address (GUnixSocketAddress): Address 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
Where can you pass these argruments to ibus? I couldn't figure out who is starting ibus in the first place.
On Arch Linux the ibus package installs /usr/share/dbus-1/services/org.freedesktop.IBus.service:
$ cat /usr/share/dbus-1/services/org.freedesktop.IBus.service
[D-BUS Service]
Name=org.freedesktop.IBus
Exec=/usr/bin/ibus-daemon --replace --panel disable --xim
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.
Most helpful comment
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.