Bug 795920 - gdm doesn't read $HOME/.dmrc
gdm doesn't read $HOME/.dmrc
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gdm (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: rc
: ---
Assigned To: Ray Strode [halfline]
Desktop QE
Depends On:
  Show dependency treegraph
Reported: 2012-02-21 14:47 EST by James Pearson
Modified: 2013-11-21 18:32 EST (History)
8 users (show)

See Also:
Fixed In Version: gdm-2.30.4-51.el6
Doc Type: Bug Fix
Doc Text:
Cause: ~/.dmrc is not consulted at login time before /var/cache/gdm/$USERNAME/dmrc Consequence: in network-mounted home directory environments, updates to ~/.dmrc (such as session and language) have no effect on machines that have logged in and out prior to the updates. Fix: GDM now consults ~/.dmrc before looking in /var/cache/gdm/$USERNAME/dmrc so that updates can take effect. Result:
Story Points: ---
Clone Of:
Last Closed: 2013-11-21 18:32:01 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Simple hack to always use $HOME/.dmrc (1.71 KB, patch)
2013-03-06 10:47 EST, James Pearson
no flags Details | Diff

  None (edit)
Description James Pearson 2012-02-21 14:47:45 EST
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):

gdm 2.30

How reproducible:

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
Actual results:

Default Session will be GNOME for this user

Expected results:

Default session for the user should be whatever is defined in $HOME/.dmrc

Additional info:

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
Comment 2 RHEL Product and Program Management 2012-12-14 03:07:54 EST
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.
Comment 3 Dan Astoorian 2013-03-05 16:07:57 EST
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.
Comment 4 James Pearson 2013-03-06 10:47:57 EST
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
Comment 5 Dan Astoorian 2013-03-06 11:26:08 EST
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.
Comment 6 James Pearson 2013-03-06 11:39:44 EST
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
Comment 8 Ray Strode [halfline] 2013-06-05 11:50:01 EDT
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.

Comment 13 Ray Strode [halfline] 2013-08-13 19:06:03 EDT
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
Comment 21 errata-xmlrpc 2013-11-21 18:32:01 EST
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.


Note You need to log in before you can comment on or make changes to this bug.