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.

devack+

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.

http://rhn.redhat.com/errata/RHBA-2013-1708.html