Vietnamese input doesn't work when I upgrade ibus to 1.5.19-1ubuntu2.1

[luongthanhlam]

Which distribution and version?: Ubuntu 19.04

Which desktop environment and version?: i3wm

Which session type?: X11

Which application and version?: All of QT apps (calibre, goldendict, telegram, keepassX, ...)

IBus version?: 1.5.19-1ubuntu2.1

Issue description:
After upgrading ibus to 1.5.19-1ubuntu2.1, all Vietnameses inputs no longer work in QT apps.
Ref: BambooEngine/ibus-bamboo#82, BambooEngine/ibus-bamboo#83

Steps to reproduce:

1. Login into i3wm
2. Open a qt app (e.g. telegram)
3. Attempt to switch to a Vietnamese IME (ibus-bamboo, ibus-unikey)

Can you reproduce your problem when you restart ibus-daemon? (yes / no): yes

Do you see any errors when you run ibus-daemon with the verbose option?:
(ibus-ui-gtk3:21599): IBUS-WARNING **: 20:47:41.669: panel.vala:255: If you launch KDE5 on xterm, export XDG_CURRENT_DESKTOP=KDE before launch KDE5.
(ibus-ui-gtk3:21599): IBUS-WARNING **: 20:47:41.765: ibus_bus_call_sync: org.freedesktop.DBus.Properties.Get: GDBus.Error:org.freedesktop.DBus.Error.Failed: No global engine.

Can you reproduce your problem with a new user account instead of the current your account? (yes / no): yes

[gunnarhj]

The change in 1.5.19-1ubuntu2.1 consists of the application of 3d442dbf as a CVE patch.

There is also this Ubuntu bug report.

[gunnarhj]

I can confirm the problem. My attempt to use IBus input methods in Kate failed, i.e. only the latin letters show up. That's the case when 3d442dbf is applied on 1.5.19 as well as 1.5.21.

[pollostrazon]

I do not want create a duplicate issue, but I can confirm the same problem also affects Debian 10 (Buster), Gnome 3.30.2, X11. Found out while using Anki and tested on other qt apps as well.
I personally do not use Vietnamese input, but Russian (translit m17n) and mozc, but the issue is identical.

[IllDepence]

Can confirm this for Ubuntu 18.04.3, i3wm, X11. Using qt applications like Anki I can't switch to Japanese input (mozc).

[gunnarhj]

The patch has been disabled for now in Ubuntu's stable releases, so @luongthanhlam and @IllDepence: You should be able to fix it by updating ibus again.

[carnil]

Hi,

On Mon, Sep 23, 2019 at 08:45:22PM -0700, luongthanhlam wrote: Closed #2137.

Why whas this issue closed, though? TTBOMK the issue was not yet fixed, but just the patch just disabled for further investigation.

[luongthanhlam]

@carnil I don't know, ibus just works well for me now. Feel free to re-open it if needed.

[pollostrazon]

Why whas this issue closed, though? TTBOMK the issue was not yet fixed, but just the patch just disabled for further investigation.

Plus the problem seems to be affecting other platforms too, so the Ubuntu patch disablement is not a solution for me on Debian. I'll open a different issue, if needed, but i didn't want to make an almost-duplicate.

[carnil]

Hi,

On Tue, Sep 24, 2019 at 02:03:07AM -0700, luongthanhlam wrote: @carnil I don't know, ibus just works well for me now. Feel free to re-open it if needed.

But this is only because the patch was reverted. This is not a solution for the original issue, thus there is need to work out why the regression happens and this needs to be fixed :-) As I did not submit the issue, I think I cannot reopen the issue itself, due to I'm neither opened the issue nor member of the project, so I think I do not have permissions to reopen the issue.

[gunnarhj]

@fujiwarat: Please re-open this issue. It was closed by mistake.

[gunnarhj]

@pollostrazon: If I was you, I'd wait a bit with submitting a new issue. I'm pretty sure that the maintainer will re-open it once he shows up.

[pollostrazon]

@pollostrazon: If I was you, I'd wait a bit with submitting a new issue. I'm pretty sure that the maintainer will re-open it once he shows up.

I think I'll do as you suggest. I don't want to be too much of an annoyance, but I'd like the problem to be solved :). Feel free to ask for more info, if needed.

[gunnarhj]

Feel free to ask for more info, if needed.

I'm not the one who will do that; maybe @fujiwarat will. OTOH, considering that the problem is easily reproducible, he may be able to nail what's causing the regression without further user input.

[carnil]

@fujiwarat, did you had a chance to look into this regression?

(Can you please reopen the bug for the regression introduced for the original CVE-2019-14822 description please?)

[fujiwarat]

I've been on vacation in this week :).
I just tried kate and konsole with ibus-unikey and ibus-mozc in XFCE4 in Fedora 30 but I cannot reproduce your problem.

Can you reproduce your problem with kate?
Can you try other desktops besides i3wm?
Does your problem depends on QT or KDE version? I tried QT 5.12 and KDE 5.59.

The CVE patch restricts to access the DBus methods in the same UID only so if you access the IBus DBus methods with another UID likes root in your environment, the access is denied now.

[changwoo]

Does your problem depends on QT or KDE version? I tried QT 5.12 and KDE 5.59.

Qt is still version 5.11.3 in Debian and based distros.

The CVE patch restricts to access the DBus methods in the same UID only so if you access the IBus DBus methods with another UID likes root in your environment, the access is denied now.

I have this issue when I run a Qt app in GNOME while GTK apps are OK. So I don't think Qt apps are running with different UID.

[gunnarhj]

I confirmed the issue with Kate. But previously I had only tested on Ubuntu (GNOME), and when installing Kate it pulled quite a few Qt dependencies (not surprisingly).

I just tested on Kubuntu (KDE Plasma), and there IBus including the CVE patch works with Kate.

So possibly this is a dependency issue on Debian/Ubuntu. To work with Qt the CVE patch seems to require some library which is present by default on a KDE desktop, but not on a GNOME desktop. The question, in that case, is which package we are talking about...

[hosiet]

(Debian maintainer for input method-related packages here)

That's a very interesting issue and it is likely to be specific to Debian derivatives. I will elaborate here.

On my Debian Unstable with Gnome 3, ps aux | grep ibus gives the following output:

hosiet    2859  0.0  0.0 388312 15072 ?        Ssl  9月25   1:52 /usr/bin/ibus-daemon --daemonize --xim
hosiet    2885  0.0  0.0 160108  6268 ?        Sl   9月25   0:00 /usr/lib/ibus/ibus-memconf
hosiet    2886  0.0  0.2 328936 40992 ?        Sl   9月25   0:00 /usr/lib/ibus/ibus-ui-gtk3
hosiet    2889  0.0  0.2 287992 34480 ?        Sl   9月25   0:30 /usr/lib/ibus/ibus-extension-gtk3
hosiet    2891  0.0  0.1 209396 27716 ?        Sl   9月25   0:08 /usr/lib/ibus/ibus-x11 --kill-daemon
hosiet    2894  0.0  0.0 233908  6476 ?        Sl   9月25   0:00 /usr/lib/ibus/ibus-portal
hosiet    2922  0.0  0.0 160104  8388 ?        Sl   9月25   0:00 /usr/lib/ibus/ibus-engine-simple
hosiet    3343  0.0  0.2 213152 44784 ?        Sl   9月25   0:37 /usr/lib//ibus/ibus-engine-sunpinyin --ibus
Debian-+ 13031  0.0  0.0 308368  8268 tty1     Sl   13:18   0:00 ibus-daemon --xim --panel disable
Debian-+ 13034  0.0  0.0 160108  7020 tty1     Sl   13:18   0:00 /usr/lib/ibus/ibus-memconf
Debian-+ 13035  1.6  0.1 281744 26340 tty1     Sl   13:18   0:00 /usr/lib/ibus/ibus-extension-gtk3
Debian-+ 13038  0.1  0.1 204172 20996 tty1     Sl   13:18   0:00 /usr/lib/ibus/ibus-x11 --kill-daemon
Debian-+ 13040  0.0  0.0 233908  7136 ?        Sl   13:18   0:00 /usr/lib/ibus/ibus-portal
Debian-+ 13048  0.0  0.0 160104  7036 tty1     Sl   13:18   0:00 /usr/lib/ibus/ibus-engine-simple
hosiet   13101  0.0  0.0   6356  2312 pts/0    S+   13:18   0:00 grep --color=auto --exclude-dir=.bzr --exclude-dir=CVS --exclude-dir=.git --exclude-dir=.hg --exclude-dir=.svn ibus

...where Debian-+ is actually Debian-gdm. It is Debian's dedicated user for running gdm.

It's weird that we have two sets of ibus-related processes running. I'm not at all an expert of it, but the Debian-gdm one could be started by GDM. Now the question is: which set of ibus is actually monitoring the DBus interface? (forgive me if there's any inaccurate words -- I'm not familiar with DBus as well) If it's the Debian-gdm one, then the regression could be explained.

I think it still needs debugging and any advice would be appreciated.

[hosiet]

I've tried to add some verbose info in bus_authorize_authenticated_peer_cb() and it seems that all those function calls are successful. However, when starting some Qt5-based applications, that function will not be invoked at all. It could still be some bugs at the Qt side.

[smcv]

's weird that we have two sets of ibus-related processes running

It isn't weird if you have one session as uid Debian-gdm (to run the "greeter" where you log in), and one session as uid hosiet (to run your actual session).

Now the question is: which set of ibus is actually monitoring the DBus interface? (forgive me if there's any inaccurate words -- I'm not familiar with DBus as well)

Normally D-Bus services are split between multiple servers:

• one "system bus" for the entire system (dbus-daemon --system), used for system services like NetworkManager, polkit and systemd. Any user can connect, but the bus acts as a security boundary: most messages are not allowed, unless a configuration file in /etc/dbus-1/system.d or /usr/share/dbus-1/system.d specifically says they are allowed.
• one "session bus" or "user bus" per user or per X11 session (dbus-daemon --session), used for per-user services like dconf, gvfs and Tracker. Only the same user who owns the bus can connect, and there is no security boundary between connections (if you can connect, you can do almost anything).
• sometimes an extra dbus-daemon per X11 display, used by AT-SPI (dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf or similar)

The gdm greeter is a miniature GNOME session running as uid Debian-gdm, so as well as its own X11 display, it gets its own dbus-daemon --session (and maybe also an AT-SPI dbus-daemon), owned by uid Debian-gdm.

ibus is unusual because it listens on its own D-Bus server socket, like a dbus-daemon, instead of connecting to the server provided by the dbus-daemon (or perhaps in addition to connecting to the dbus-daemon). You can see it in netstat --unix --listen -p. It is that socket that had a security vulnerability, which was fixed by 3d442db.

According to private discussion before the security vulnerability was fixed, ibus was meant to have the same security model (and presumably the same session model) as dbus-daemon --session: only the same uid who owns the ibus processes can connect to the server.

[smcv]

I've tried to add some verbose info in bus_authorize_authenticated_peer_cb() and it seems that all those function calls are successful. However, when starting some Qt5-based applications, that function will not be invoked at all.

@hosiet: Are those Qt5-based applications perhaps using the DBUS_COOKIE_SHA1 authentication mechanism, instead of the recommended EXTERNAL? Adding debugging to bus_allow_mechanism_cb() might tell you.

[gunnarhj]

@hosiet: I don't see two sets of ibus processes in unstable, and neither in Ubuntu 19.10. But indeed I have seen it in a few Ubuntu version before 19.10.

Anyway, I have done some testing which may or may not be of interest. In any case it shows that the issue with Qt apps is present also in other environments but GNOME/GDM:

I played with an Ubuntu MATE installation. To start with I installed Kate, and found that the Qt issue with the CVE patch is present also on MATE.

Then I installed the kubuntu-desktop package, which pulls all the packages needed for the Plasma desktop. As long as I kept LightDM as the display manager, the Qt issue was there both in MATE and Plasma sessions.

But switching from LightDM to SDDM made a difference. Suddenly IBus worked with Kate in Plasma sessions. Still not in MATE sessions, though.

I enabled logging of ibus-daemon, but nothing was written to the log when it failed.

[smcv]

I don't see two sets of ibus processes in unstable

In some versions and configurations of GNOME (I think it's mainly affected by the gdm version and by X11 vs. Wayland), the gdm "greeter" session is terminated after switching to a different virtual console for your real session, and only restarted when you switch back to tty1. In those versions and configurations, you would not have a second set of ibus processes for Debian-gdm.

[smcv]

switching from LightDM to SDDM made a difference ... with Kate in Plasma sessions

It would probably be useful to compare the environment variables that are set in these two situations.

In some X11 display managers, the X11 display that was started for the login screen is kept and used for the user session; in others, a new X11 display is started on a different virtual console. This might also matter.

[gunnarhj]

switching from LightDM to SDDM made a difference ... with Kate in Plasma sessions

It would probably be useful to compare the environment variables that are set in these two situations.

I must correct myself: During today's exercise IBus worked in Qt also when Plasma was used together with LightDM. So to summarize it works in Plasma but not in MATE sessions.

What strikes me is that in the MATE sessions (where Qt does not work) I have env variables like:

DBUS_STARTER_ADDRESS=unix:path=/run/user/1000/bus,guid=098ddeff47308e51bf4131a85d8f5ebc
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus,guid=098ddeff47308e51bf4131a85d8f5ebc

while in the Plasma sessions (where Qt works) I only have:

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

Attached please find the environment variables in all four combos.

env-vars-from-tests.tar.gz

[smcv]

As long as you have DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus (with or without guid), anything that wants the D-Bus session bus should be able to connect to it without incident.

(Actually that path is used by default if your XDG_RUNTIME_DIR is /run/user/1000, so it would work even without DBUS_SESSION_BUS_ADDRESS.)

However, that's the standard session bus, not ibus' private server socket. I don't know how ibus clients locate its private server.

[smcv]

The client use the /usr/lib*/qt5/plugins/platforminputcontexts/libibusplatforminputcontextplugin.so when the environment variable QT_IM_MODULE=ibus is exported.
https://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforminputcontexts/ibus

OK, so it is a QtDBus client, which behind the scenes uses a private libdbus connection.

In that case, I would have expected the strace output in the client (Kate) to include a failed attempt to connect to the abstract Unix socket described by $HOME/.config/ibus/bus/${a_socket_file}.

[smcv]

A strace of the ibus-daemon at the time that a non-working client connects might also reveal some useful information.

[fujiwarat]

strace of kate:
kate-strace.txt

strace of ibus-daemon
ibus-strace.txt

Since I sometimes reproduce this issue, the strace of ibus-daemon includes some succeeded connections and the last failed connection.

I think if the client failed to connect ${a_socket_file}, this issue could be reproduced without the latest patch. But this issue is not reproduced in ibus 1.5.21 without the latest patch and I guess the ${a_socket_file} connection would not be relative with this issue.

[smcv]

I don't see any failing authentication conversations in those logs, only successful ones. Are you perhaps not tracing all threads? (strace -f)

You don't necessarily need to attach the whole log, only the parts that include the unsuccessful authentication/authorization handshake. You can recognise the authentication handshake by searching for AUTH being sent or received.

Here is an example of a successful authentication/authorization handshake from kate-strace.txt, where it connects to the session bus:

socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 7
fcntl(7, F_GETFL)                       = 0x2 (flags O_RDWR)
fcntl(7, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
connect(7, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 110) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
getpid()                                = 14110
geteuid()                               = 1000
getegid()                               = 1000
getpid()                                = 14110
geteuid()                               = 1000
getegid()                               = 1000
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7f9f88b94fe8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
sendmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=14110, uid=1000, gid=1000}}], msg_controllen=32, msg_flags=0}, MSG_NOSIGNAL) = 1
sendto(7, "AUTH\r\n", 6, MSG_NOSIGNAL, NULL, 0) = 6
recvfrom(7, "REJECTED EXTERNAL\r\n", 4096, 0, NULL, NULL) = 19
sendto(7, "AUTH EXTERNAL 31303030\r\n", 24, MSG_NOSIGNAL, NULL, 0) = 24
recvfrom(7, "OK 92d4bfefa2a89fbf1e199444609e5"..., 4096, 0, NULL, NULL) = 37
sendto(7, "NEGOTIATE_UNIX_FD\r\n", 19, MSG_NOSIGNAL, NULL, 0) = 19
recvfrom(7, "AGREE_UNIX_FD\r\n", 4096, 0, NULL, NULL) = 15
sendto(7, "BEGIN\r\n", 7, MSG_NOSIGNAL, NULL, 0) = 7

The unsuccessful handshake would look similar, but instead of having OK ... BEGIN, it would look more like this:

• client: AUTH\r\n
• server: REJECTED EXTERNAL\r\n
• client: AUTH EXTERNAL 31303030\r\n
• server: REJECTED EXTERNAL\r\n
• client disconnects

I am particularly interested in any calls to getpid(), geteuid(), getuid(), sendmsg(..., cmsg_type=SCM_CREDENTIALS, ...), or getsockopt (..., SOL_SOCKET, SO_PEERCRED, ...) that happen close to that conversation.

[fujiwarat]

I put the log of strace -f kate.
kate-strace3.txt

Here is the log of strace -f ibus-daemon --xim
ibus-strace2.log

[smcv]

Thanks, this is better. In the new kate log I can see a QDBusConnection thread trying to authenticate. EXTERNAL authentication fails, and it falls back to trying DBUS_COOKIE_SHA1.

[pid 23017] prctl(PR_SET_NAME, "QDBusConnection"...) = 0
[pid 23017] poll([{fd=16, events=POLLIN}], 1, 0) = 1 ([{fd=16, revents=POLLIN}])
[pid 23017] read(16, "\1\0\0\0\0\0\0\0", 16) = 8
[pid 23017] socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0) = 17
[pid 23017] connect(17, {sa_family=AF_UNIX, sun_path=@"/tmp/ibus/dbus-xwEppw2X"}, 26) = 0
[pid 23017] fcntl(17, F_GETFL)          = 0x2 (flags O_RDWR)
[pid 23017] fcntl(17, F_SETFL, O_RDWR|O_NONBLOCK) = 0
[pid 23017] geteuid()                   = 1000
[pid 23017] getsockname(17, {sa_family=AF_UNIX}, [128->2]) = 0
[pid 23017] poll([{fd=17, events=POLLOUT}], 1, 0) = 1 ([{fd=17, revents=POLLOUT}])
[pid 23017] sendto(17, "\0", 1, MSG_NOSIGNAL, NULL, 0) = 1
[pid 23017] sendto(17, "AUTH EXTERNAL 31303030\r\n", 24, MSG_NOSIGNAL, NULL, 0) = 24
[pid 23017] poll([{fd=17, events=POLLIN}], 1, -1) = 1 ([{fd=17, revents=POLLIN}])
[pid 23017] read(17, "REJECTED EXTERNAL DBUS_COOKIE_SH"..., 2048) = 36
[pid 23017] geteuid()                   = 1000
[pid 23017] poll([{fd=17, events=POLLOUT}], 1, -1) = 1 ([{fd=17, revents=POLLOUT}])
[pid 23017] sendto(17, "AUTH DBUS_COOKIE_SHA1 31303030\r\n", 32, MSG_NOSIGNAL, NULL, 0) = 32
[pid 23017] poll([{fd=17, events=POLLIN}], 1, -1) = 1 ([{fd=17, revents=POLLIN}])
[pid 23017] read(17, "DATA 6f72675f67746b5f67646275735"..., 2048) = 87
[pid 23017] getpid()                    = 23012
[pid 23017] geteuid()                   = 1000
[pid 23017] getuid()                    = 1000
[pid 23017] geteuid()                   = 1000
[pid 23017] stat("/home/tfujiwar/.dbus-keyrings", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0

Unlike GDBus clients, libdbus-based clients do not explicitly send credentials on Linux: they just send \0 and rely on the server to use getsockopt SO_PEERCRED:

[pid 23017] sendto(17, "\0", 1, MSG_NOSIGNAL, NULL, 0) = 1

In the ibus-daemon, we can see the GDBusServer handling this connection attempt:

[pid 23253] prctl(PR_SET_NAME, "pool-ibus-daemo"...) = 0
[pid 23253] getsockopt(21, SOL_SOCKET, SO_PASSCRED, [0], [4]) = 0
[pid 23253] setsockopt(21, SOL_SOCKET, SO_PASSCRED, [1], 4) = 0
[pid 23253] recvmsg(21, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=0, uid=65534, gid=65534}}], msg_controllen=32, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 1
[pid 23253] getpid()                    = 23207
[pid 23253] geteuid()                   = 1000
[pid 23253] getegid()                   = 1000
[pid 23253] setsockopt(21, SOL_SOCKET, SO_PASSCRED, [0], 4) = 0
[pid 23253] recvfrom(21, "AUTH EXTERNAL 31303030\r\n", 4096, 0, NULL, NULL) = 24
[pid 23253] sendto(21, "REJECTED EXTERNAL DBUS_COOKIE_SH"..., 36, MSG_NOSIGNAL, NULL, 0) = 36
[pid 23253] recvfrom(21, "AUTH DBUS_COOKIE_SHA1 31303030\r\n", 4096, 0, NULL, NULL) = 32

The GDBus server code assumes that the kernel will not attach a SCM_CREDENTIALS message if the client didn't send one, but it seems that what actually happens is that the kernel sends a message indicating pid 0, uid 65534 and gid 65534:

[pid 23253] recvmsg(21, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\0", iov_len=1}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=0, uid=65534, gid=65534}}], msg_controllen=32, msg_flags=MSG_CMSG_CLOEXEC}, MSG_CMSG_CLOEXEC) = 1

I think this is a GDBusServer bug. If GDBusServer receives a SCM_CREDENTIALS message that looks like that, it should probably fall back to using getsockopt SO_PEERCRED, the same as if there was no SCM_CREDENTIALS message at all.

[smcv]

https://gitlab.gnome.org/GNOME/glib/issues/1831

[fujiwarat]

@smcv Thank you for the evaluation.

[fujiwarat]

I think the workaround would be to run ibus restart several times and you sometimes could connect to ibus-daemon.

[smcv]

I hope https://gitlab.gnome.org/GNOME/glib/merge_requests/1176 will fix this.

[gunnarhj]

I hope https://gitlab.gnome.org/GNOME/glib/merge_requests/1176 will fix this.

I built glib2.0 with that MR, and it did make a difference. With modified libglib2.0-* packages I can no longer reproduce the Qt issue on Ubuntu with GNOME or Ubuntu MATE.

[buhtz]

I can confirm problems with IBus (Japanese via Anthy) on Debian 10 with the applications Anki and JabRef.
All other applications i tested (e.g. Terminator terminal, Mousepad, Firefox, etc) are working fine.

JabRef/jabref#5255

Debian Input Method Mailing List
https://lists.debian.org/debian-input-method/2019/10/msg00047.html

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941018

[fujiwarat]

I verified the fix. Thank you.

[buhtz]

Side information:
On Debian 10 some modifications where done and JabRef works again witih ibus-anthy. But Anki (2.1.15) still not working.

[fujiwarat]

I tried anki 2.1.15 in Fedora 30 and works fine.

[smcv]

On Debian 10 some modifications where done

This bug has not yet been fixed in Debian 10. An update package has been proposed but needs release team approval.

[smcv]

Is there a way I can test this on a Debian virtual machine with GNOME and some Qt app (for example anki), without understanding Japanese or other languages that normally use ibus?

[gunnarhj]

Is there a way I can test this on a Debian virtual machine with GNOME and some Qt app (for example anki), without understanding Japanese or other languages that normally use ibus?

Absolutely; I do that often. Just install some IBus input method e.g. ibus-anthy, relogin, add it as input source and start typing. The beautiful characters which ought to show up are easy to distinguish from latin letters. :)

[juhp]

I believe the latest upstream glib 2.62.3 and 2.63.2 releases now have the necessary fix for this.

[mayquanxi]

I also had a issue similar with ibus for vietnamese, i can input vietnamese on system and libreoffice but can not input on web browser. I had looking for issue in few day but not result, anyone help me?
i use ibus 1.5.21 newest

[fujiwarat]

@mayquanxi Is your web browser based on QT? If not, your problem is not this.

[Silgrond]

I still have this issue with Anki 2.1.21 and ibus 1.5.22 on Solus using mozc.
I have tried looking for the glib_required_version on ibus/configure.ac, but I don't seem to have this file anywhere on my filesystem. Can anyone help me?

[changwoo]

@Silgrond You don't have to modify configure.ac (which is a file in the source tree) to fix your problem. It seems that your installed Solus has old version of glib. You need newer version of glib (even with a Qt client app); glib 2.62.3 or higher but not 2.63.0.

[changwoo]

@J-J-Chiarella Nope. Please check how a closed issue has been resolved before referring other issues.

[J-J-Chiarella]

@changwoo I did check. This issue here relating to using ibus with Qt was fixed with glib, but I don't know if glib is involved with what I reported. I thought maybe Qt wasn't playing nice with various things and that was causing it to not work with ibus. The problems I had with ibus were the same before and after a glib update. I watched this issue when I was running the earlier version of glib last year. As I reported in the other issue, the issues I encountered were different depending on which engine I was using. Honest mistake in wondering if these were related. I cannot understand 90% of what is in that referenced glib code merge. I can just test and report my experiences. Other comment deleted.