Red Hat Bugzilla – Bug 184351
wrong user settings used for users with same uid
Last modified: 2008-08-02 19:40:33 EDT
Description of problem:
If there are multiple login names with the same uid, logging into gnome
consistently causes the settings of one of them to prevail over the other's.
The point of my creating two user names with the same uid but different home
dirs was precisely to be able to share files easily but have different
configurations, say, one for local use of my notebook, one for using it as a vnc
client that can also run local programs, thus using different keyboard shortcuts
for switching between virtual desktops, etc. Unfortunately, the username I just
created for the latter purpose ended up not even getting a chance to have its
own gnome settings, everything was used from the original user, whose settings
were to be ignored.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Create one user with a given uid and home dir
2.Log into gnome and change some settings, say, add gnome-terminal to the set of
applications to be started when the session starts
3.Create another user with the same uid, but different username and home dir
4.Log into gnome as this alternate username
Settings from the first user prevail, so you get gnome-terminal started, and
it's in the wrong home dir.
Independent settings for usernames that have different home dirs.
I don't think this is something that's really expected to work.
getpwuid() doesn't return a list, for instance.
GConf2 isn't likely the right component either. gnome-session starts start up
programs based on desktop files in $HOME/.config/autostart
So $HOME is probably set wrong. So probably either GDM set it wrong, or pam set
If you login to the console and startx do things work as expected?
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present. Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.
Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.
Thank you in advance.
(this message is mass message)