Red Hat Bugzilla – Bug 491319
g_get_user_name / g_get_home_dir should check LOGNAME
Last modified: 2013-04-30 18:54:33 EDT
Description of problem:
This problem occurs with RHEL-4 u7.
Customer has two users with same uid viz. foo and ,say, ccfoo. She logs in as foo and sets $LOGNAME to ccfoo as well. By default it is set as foo based on uid since foo was created first.
When she starts up X-Windows and runs firefox (3.0), firefox shows an error "error occurred while loading or saving configuration information for Gecko". The core issue is that gconf is trying to acquire a lock for /tmp/gconfd-ccfoo/lock/ior whereas gconfd has created /tmp/gconfd-foo/lock/ior.
This problem does not occur, when using firefox 22.214.171.124 in RHEL-4 u6.
It turns out firefox 3 links against glib-2.0 in /usr/evolution28/lib, which implements g_get_user_name() differently compared to that in /usr/lib used byg gconf. The difference is:
* g_get_user_name() in evolution28 returns the contents of $LOGNAME provided it matches against the current uid.
* g_get_user_name() in /usr/lib returns the user name associated by default to the current uid.
gconfd and firefox link against the two different versions, thus causing a mismatch in their interpretation of user names.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
For firefox error:
1) Create two user names with same uid:
useradd -u 666 -o foo
useradd -u 666 -o ccfoo
2) log in as ccroot
3) Open a terminal and type:
The error described above
Firefox should simply start with profile of foo.
Test case to verify return value of g_get_user_name:
$ cat ggetusername.c
$ gcc -o stockglib ggetusername.c `pkgconfig --cflags --libs glib-2.0`
$ gcc -o evlglib ggetusername.c /usr/evolution28/lib/libglib-2.0.a -I/usr/evolution28/include/glib-2.0 -I/usr/evolution28/lib/glib-2.0/include
$ LOGNAME=ccfoo ./evlglib
$ LOGNAME=ccfoo ./stockglib
Handle multiple user names with the same UID better.
(#319535, Laszlo Peter)
* glib/gutils.c (g_get_any_init_do): When determining user
data, first look up $LOGNAME. If the UID doesn't match
getuid(), fall back to the current behaviour of looking
up the user data based on getuid().
Created attachment 336035 [details]
patch based on upstream code
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.