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): GConf2-2.13.5-5 How reproducible: Every time 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 Actual results: Settings from the first user prevail, so you get gnome-terminal started, and it's in the wrong home dir. Expected results: Independent settings for usernames that have different home dirs. Additional info:
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 it wrong. 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)