After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319535 - g_get_user_name / g_get_home_dir should check LOGNAME?
g_get_user_name / g_get_home_dir should check LOGNAME?
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.8.x
Other Solaris
: Normal minor
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2005-10-23 14:20 UTC by Laszlo (Laca) Peter
Modified: 2011-02-18 15:49 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
patch for looking up the current user based on logname (1.49 KB, patch)
2005-10-23 14:21 UTC, Laszlo (Laca) Peter
needs-work Details | Review

Description Laszlo (Laca) Peter 2005-10-23 14:20:01 UTC
This is a minor issue really...

On most Unix and Unix-like systems it is perfectly normal to have 2 users
with the same UID.  For example I have a 'laca' and a 'laca-gtest' user
with the same user id but different homes so that the preferences are not
shared.

However GNOME currently only uses the home directory of 'laca' because
g_get_user_name, g_get_home_dir and their friends look up the UID using
getpwuid_r() and they will always return the info belonging to the first
user that matches the UID in the password database.

It seem that the only program that really knows what the user name of the
current user is is the login manager, in this case gdm (or login in case
of the command line login and sometimes dtlogin on Solaris).  All of these
programs set $HOME and $LOGNAME.  $HOME seems to be the most reliable
however there's no getpw.* function that would be directly usable for
looking up $HOME.  There is getpwnam_r() for looking up the
login name.

I'm using the attached patch to fix this issue on my system.
It looks up $LOGNAME first, then checks if the UID matches getuid()
(since the user could have changed the LOGNAME env. var) and if
either of these fails, it falls back to the current behaviour,
which is to look up the UID.  Works fine for me, but I only ever
tested it on Solaris.
Comment 1 Laszlo (Laca) Peter 2005-10-23 14:21:51 UTC
Created attachment 53788 [details] [review]
patch for looking up the current user based on logname
Comment 2 Matthias Clasen 2005-11-11 05:52:44 UTC
> On most Unix and Unix-like systems it is perfectly normal to have 2 users
> with the same UID

Not sure that is really true. At least I hadn't heard of this pracise before.
Comment 3 Laszlo (Laca) Peter 2005-11-14 02:07:40 UTC
I admit it's a bit unusual.  I couldn't find a definitive answer only some
hints that many software products are or are not prepared for this scenario
and a quote from O'Reilly's Practical Unix and Internet Security:

>> The second exception to the rule about only one username per UID is when 
   you have multiple people with access to a system account, including the
   superuser account, and you want to track their activities via the audit
   trail. By creating separate usernames with the same UID, and giving the
   users access to only one of these identities, you can do some monitoring
   of usage. You can also disable access for one person without disabling
   it for all.<<

(the 1st exception it mentions is about uucp...)

The issue was originally reported by one of our very senior engineers but
then I remembered using this technique to avoid using my NFS home directory
on test machines.  I set up a local user with the same uid as my NIS uid
and a local home dir.
Comment 4 Matthias Clasen 2005-12-02 21:27:55 UTC
If anything, we should probably use logname() instead of looking for an
environment variable.
Comment 5 Matthias Clasen 2005-12-04 07:01:00 UTC
2005-12-04  Matthias Clasen  <mclasen@redhat.com>

	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().