Red Hat Bugzilla – Bug 204727
Unicode representation of user's full name.
Last modified: 2007-11-30 17:11:41 EST
Description of problem:
While creating a new user or editing an existing one, one can not type the full
name of the user in Unicode (using Ctrl+<space> to get the SCIM menu). However
the same string can be copy-pasted from somewhere else (eg., GEdit).
Version-Release number of selected component (if applicable):
Can be reproduced every time as follows:
Steps to Reproduce:
1. Open system-config-users: # system-config-users
2. Double-click an existing user, or try to create a new one.
3. Try to type the user's full name in Unicode, using ctrl+<space> to get the
Menu would not pop-up, although it is possible to copy paste from somewhere
else, like GEdit
A SCIM menu ought to have popped out to allow the user to chose the language.
GTK_IM_MODULE environment variable seems to be ignored - for testing, I did
enable the IM context menu, and when s-c-users runs, current IM pointed to XIM.
it works after changing it to scim from the IM context menu. I'm not sure why.
consolehelper may drops the environment variables perhaps like sudo does in some
Reassigning to usermode then, this is nothing I can fix in s-c-users.
Matthias, can you please confirm that using an user-supplied, untrusted
GTK_IM_MODULE value within a GTK+ application run by root is secure?
Also, can any of the substrings "..", "/" and "%" legitimately appear in the
value of GTK_IM_MODULE?
This issue is present in Rawhide (updated Fedora 7 test 4) as well.
with latest rawhide (after F8 release), problem continue...
In reponse to comment #4: no, I cannot confirm that.
Running GUI applications as root is really not the right approach, and the gtk
team has been saying that for years. See PolicyKit for how to do this right.
(In reply to comment #4)
> Also, can any of the substrings "..", "/" and "%" legitimately appear in the
> value of GTK_IM_MODULE?
Normally GTK_IM_MODULE is just the name of the gtk immodule:
eg "scim" or "scim-bridge".
(In reply to comment #8)
> In reponse to comment #4: no, I cannot confirm that.