Red Hat Bugzilla – Bug 490143
ibus issue with gnome-keyring
Last modified: 2013-01-10 00:05:33 EST
I spotted the following in the logs:
Mar 13 09:40:15 localhost gnome-keyring-ask: IBUS: Connect to unix:path=/tmp/ibus-(null)/ibus--0.0 failed. In D-Bus address, character '(' should have been escaped#012.
Looks like ibus fails to get the username when used in the gnome-keyring password dialog.
Looking at ibus_get_user_name(), it is no wonder...
Some further hints from Ray:
- should ideally just use an abstract socket
- definitively don't use the hostname in the socket name, since it is not something thats stable over time and can be relied on (NM sets it dynamically)
Please tell me how to use /usr/libexec/gnome-keyring-ask, and then I could debug it, and find a right way to get user name in gnome-keyring-ask
Why I use user name in socket address instead of use random named abstract socket? It is because of below reasons:
1. ibus-daemon is not started before all applications. So It can not tell client applications the address name via an env variable like $DBUS_SESSION_BUS_ADDRESS.
2. ibus has a feature: The ibus-daemon can be stopped and re-started in any time. So we should have a method to let im modules can be notified when the daemon is executed. Currently, im modules will watch the folder /tmp/ibus-$USERNAME/ by inotify, and receive notify when socket file is created or removed. I don't know another better methods.
Do you have some suggestions?
gnome-keyring-ask is the dialog that comes up to unlock your keyring.
Not sure about about the abstract socket then, but the point about the hostname still stands.
Wrt to the user name, this commit will improve things in the next release:
2009-03-16 Stef Walter <email@example.com>
* library/gnome-keyring-utils.c: Set USERNAME
and LOGNAME environment variables in daemon when
starting up. Fixes bug #575262. Reported by Matthias Clasen
So I move this bug to gnome-keyring, and wait the next release.
You still need to fix the hostname problem
Sorry. What's the hostname problem? Please give me some detail.
The ibus session is bind to X session. Each X sessions will have a separated ibus. So the socket address includes some info from $DISPLAY env variable.
DISPLAY=localhost:0.0, the address will be ibus-$USERNAME/ibus-localhost-0.0
DISPLAY=other_xserver_ip:0.0, the address will be ibus-$USERNAME/ibus-other_xserver_ip-0.0
DISPLAY=:0.0, the address will be ibus-$USERNAME/ibus--0.0
Ok, so you just use the hostname part of the DISPLAY.
There are still several problems here.
- You assume that $DISPLAY is set. While this is normally the case, it is by no means guaranteed. Example:
gedit --display :1.0
- You assume that $DISPLAY is unique. But it is easy to come up with examples where different DISPLAY strings give you a connection to the same server, e.g.
- You say that your ibus server is bound to the X session, but your socket name depends on the screen that something is started on:
DISPLAY=:0.1 gedit # oops, no input methods on screen 1
I understood the problem now. Do have some suggestions? Do you know some better methods to get the unique information from the current X session (or X Server)?
BTW, I think the ibus socket address must include the hostname. If the Xserver is running on different host, host name is important to distinguish the sessions with other Xserver running on different hosts with same display number.
I tried fixed this issue by follow ways.
1. Remove screen number from socket address
2. Get the DISPLAY from gdk_display_get_name
3. If the hostname in DISPLAY is empty. I will use unix as hostname
Modified in ibus-220.127.116.1190331-1
Please try it.
mclasen says it can be closed now.