Bug 491319 - g_get_user_name / g_get_home_dir should check LOGNAME
g_get_user_name / g_get_home_dir should check LOGNAME
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glib2 (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Cosimo Cecchi
Depends On:
  Show dependency treegraph
Reported: 2009-03-20 08:39 EDT by ritz
Modified: 2013-04-30 18:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-06-14 15:38:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch based on upstream code (1.94 KB, patch)
2009-03-20 08:40 EDT, ritz
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 319535 None None None Never

  None (edit)
Description ritz 2009-03-20 08:39:41 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 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):

How reproducible:

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:
LOGNAME=ccfoo firefox

Actual results:
The error described above

Expected results:
Firefox should simply start with profile of foo.

Additional info:

Test case to verify return value of g_get_user_name:

$ cat ggetusername.c
#include <glib.h>

int main()
       printf("%s\n", g_get_user_name());

$ 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().
Comment 1 ritz 2009-03-20 08:40:36 EDT
Created attachment 336035 [details]
patch based on upstream code
Comment 4 RHEL Product and Program Management 2010-10-22 15:04:26 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.