Description of problem:
At login, gdm tries to use /var/cache/gdm/$USERNAME/drmc and ignores whatever is in $HOME/.dmrc
/var/cache/gdm/$USERNAME/drmc _may_ be a copy of $HOME/.dmrc - but this is not always the case - especially on systems with shared home directories (e.g. NFS)
Version-Release number of selected component (if applicable):
It will always read /var/cache/gdm/$USERNAME/drmc and never $HOME/.dmrc
Steps to Reproduce:
1. Install a new 6.x system with Gnome and KDE
2. Create new user
3. Create a suitable $HOME/.dmrc with say 'Session=kde'
4. Log in via gdm as the above user
Default Session will be GNOME for this user
Default session for the user should be whatever is defined in $HOME/.dmrc
It appears that the contents of $HOME/.dmrc and /var/cache/gdm/$USERNAME/drmc do get sync'd up - but this only seems to happen if the user changes the session they want at log in time
This problem shows up when there are multiple workstations that a user may use over the course of time - if a user logs into a new workstation, their $HOME/.dmrc is not used and some default will be used instead.
If users change their default session on one machine, this will not be reflected on other machines they may subsequently log in to
If $HOME/.dmrc is readable and correct, then it should be used instead of /var/cache/gdm/$USERNAME/drmc
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
The current behaviour can lead to even more insidious problems. For example:
- user accidentally logs into GDM on Workstation 1 with the language set incorrectly (e.g., to Traditional Chinese). This sets "Language=zh_TW.utf8" in /var/cache/gdm/$USERNAME/drmc and $HOME/.dmrc. User then logs out.
- user later logs in (without touching the GDM language menu) to workstation 2, which shares the user's home directory. Since there is no /var/cache/gdm/$USERNAME/drmc, the user gets logged in using the system's default language; however, as part of the login process, $HOME/.dmrc gets copied to /var/cache/gdm/$USERNAME/drmc on workstation 2. If the user then logs out and back in, the next session will be in Traditional Chinese.
- user eventually notices the problem and sets the language back to US English on the GDM login screen on Workstation 2, fixing /var/cache/gdm/$USERNAME/drmc and $HOME/.dmrc. User thinks the problem is fixed.
- some time later, the user goes back to use Workstation 1 again, which still has /var/cache/gdm/$USERNAME/drmc set to Traditional Chinese. They get a Traditional Chinese session, and $HOME/.dmrc gets set back to Traditional Chinese again.
This can make an incorrect language setting migrate almost virally between workstations.
Created attachment 706079 [details]
Simple hack to always use $HOME/.dmrc
We've been using a hacked gdm for the past year that always uses $HOME/.dmrc (and ignores /var/cache/gdm/$USERNAME/drmc), which has been working without problems
I've attached a patch against the latest gdm (2.30.4-39) - if it is of any use - although it doesn't really 'fix' the problem as such
Does this patch work if $HOME/.dmrc is not world-readable?
It's not clear to me how this should be fixed--in general, $HOME/.dmrc may not be available to GDM until the user has authenticated. But using the defaults for the current session while changing /var/cache/gdm/$USERNAME/drmc to take effect for subsequent sessions is unintuitive and creates serious problems.
At a minimum, $HOME/.dmrc should not be copied to /var/cache/gdm/$USERNAME/drmc after logging in if its settings cannot be applied to the current session.
The patch probably won't help if $HOME/.dmrc is not world-readable - although this isn't a problem in our case - the patch is what we use, but it only works round the issue - I said previously, it isn't a really a fix
we can't reliably read ~/.dmrc at the time the session selector first shows up because the user's home directory may not be available until after the user has entered their password. Furthermore, root may not have access to ~/.dmrc if root squashing is enabled.
I guess we could try to read ~/.dmrc if the cache file doesn't exist. It won't work in some cases, but should help with the specific case mentioned in comment 0.
I'm building a fix to consult ~/.dmrc first and fallback to the cached copy if ~/.dmrc fails. It will fail in some typical situations. Clearly, it's not going to work if the user's login credentials are required to access the home directory
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.