Bug 795920
Summary: | gdm doesn't read $HOME/.dmrc | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | James Pearson <james-p> | ||||
Component: | gdm | Assignee: | Ray Strode [halfline] <rstrode> | ||||
Status: | CLOSED ERRATA | QA Contact: | Desktop QE <desktop-qa-list> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 6.2 | CC: | djast, jhunt, lnovich, mdomonko, rstrode, tlavigne, tpelka, vincent | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
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: | Environment: | ||||||
Last Closed: | 2013-11-21 23:32:01 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
James Pearson
2012-02-21 19:47:45 UTC
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 |