Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to use ibus-daemon in firejail #116

Closed
pyamsoft opened this issue Nov 3, 2015 · 36 comments

Comments

@pyamsoft
Copy link

commented Nov 3, 2015

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:

  1. Install ibus-daemon, and in my case, ibus-anthy for Japanese input and noto-fonts-cjk for East Asian fonts.
  2. Start ibus daemon with ibus-daemon -drx
  3. Launch mousepad, switch the language in ibus from English to Japanese.
  4. Upon typing, Japanese characters will be displayed as expected.
  5. Launch a firejail instance of mousepad
  6. Switch language from English to Japanese
  7. Upon typing, English is still output, even though Japanese was requested.
@netblue30

This comment has been minimized.

Copy link
Owner

commented Nov 3, 2015

I'll look into it, thanks.

@netblue30 netblue30 added the bug label Nov 3, 2015

@netblue30

This comment has been minimized.

Copy link
Owner

commented Nov 4, 2015

Fixed!

@netblue30 netblue30 closed this Nov 4, 2015

@pyamsoft

This comment has been minimized.

Copy link
Author

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

  1. Create a new bridge network device br0
  2. Pass the bridge device to firejail using the --net=br0 option
  3. Launch any graphical program like chromium / mousepad (anything that can talk with ibus)
  4. Attempt to type

Excepted: 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 netblue30 reopened this Nov 4, 2015

@netblue30

This comment has been minimized.

Copy link
Owner

commented Nov 5, 2015

I've disabled the previous fix if a network ns is created by the sandbox.

@pirate486743186

This comment has been minimized.

Copy link
Contributor

commented 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

This comment has been minimized.

Copy link
Owner

commented 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

This comment has been minimized.

Copy link

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

  1. firejail firefox
  2. open new tab and type url
  3. amixer shows error "Mixer attach default error: Connection refused"
@netblue30

This comment has been minimized.

Copy link
Owner

commented Jan 18, 2016

This looks more like a sound problem. Do you have PulseAudio installed, or only ALSA?

@ioparaskev

This comment has been minimized.

Copy link

commented 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%"

shm_open() failed: No such file or directory
Connection failure: Protocol error
shm_open() failed: No such file or directory
Connection failure: Protocol error

@netblue30

This comment has been minimized.

Copy link
Owner

commented 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

This comment has been minimized.

Copy link

commented Jan 21, 2016

oh I see.. thanks and sorry for hijacking this

@netblue30

This comment has been minimized.

Copy link
Owner

commented Jan 23, 2016

No problem!

@pyamsoft pyamsoft referenced this issue Apr 28, 2016
@pirate486743186

This comment has been minimized.

Copy link
Contributor

commented May 9, 2016

Same in Ubuntu 16.04

@dfaerch

This comment has been minimized.

Copy link

commented 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

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

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link

commented Jan 10, 2017

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.

@netblue30

This comment has been minimized.

Copy link
Owner

commented Jan 12, 2017

Thanks for the info, I'll document it on the web site.

@anatoli26

This comment has been minimized.

Copy link

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

@netblue30

This comment has been minimized.

Copy link
Owner

commented Mar 26, 2017

I'll give it a try, thanks.

@pdo-smith

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link

commented 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

This comment has been minimized.

Copy link
Collaborator

commented Jun 7, 2018

Is this still an issue and do the workarounds above not work?

@dfaerch

This comment has been minimized.

Copy link

commented Jun 12, 2018

@chiraag-nataraj my issue has resolved itself over time. works-for-me

@graywolf

This comment has been minimized.

Copy link
Contributor

commented Jul 5, 2018

I still have the issue, GTK_IM_MODULE=ibus firefox does not work. I don't think this should be closed.

@chiraag-nataraj

This comment has been minimized.

Copy link
Collaborator

commented Jul 8, 2018

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

@chiraag-nataraj

This comment has been minimized.

Copy link
Collaborator

commented Aug 6, 2018

@graywolf, have you tried the workarounds on this thread?

@graywolf

This comment has been minimized.

Copy link
Contributor

commented 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 ibus/ibus#2020 (comment)

@chiraag-nataraj

This comment has been minimized.

Copy link
Collaborator

commented 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

This comment has been minimized.

Copy link
Contributor

commented Aug 14, 2018

I guess... 🍡

@chiraag-nataraj

This comment has been minimized.

Copy link
Collaborator

commented 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

This comment has been minimized.

Copy link
Collaborator

commented Aug 22, 2018

On second thought, re-opening, since this is still an issue that should be debugged.

@xelxebar

This comment has been minimized.

Copy link

commented Nov 4, 2018

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

This comment has been minimized.

Copy link

commented 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/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.

@biergaizi

This comment has been minimized.

Copy link

commented Feb 4, 2019

Awesome! Having the capability to use an alternative IPC socket should definitely solve the problem.

@chiraag-nataraj

This comment has been minimized.

Copy link
Collaborator

commented May 20, 2019

Given the workaround @mhva suggested, do people still have this issue?

@chiraag-nataraj

This comment has been minimized.

Copy link
Collaborator

commented 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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.