Bug 1417219

Summary: Prevent gdm to access user's home without completing the authentication process.
Product: Red Hat Enterprise Linux 6 Reporter: amit yadav <ayadav>
Component: gdmAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED ERRATA QA Contact: Desktop QE <desktop-qa-list>
Severity: high Docs Contact:
Priority: high    
Version: 6.5CC: bgollahe, dkochuka, jkurik, rstrode, tpelka, vchoudha
Target Milestone: rcKeywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: gdm-2.30.4-69.el6 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-06-19 05:16:14 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1461138, 1492868    

Description amit yadav 2017-01-27 15:03:37 UTC
Description of problem:

Starting with RHEL6.5, when the user enters his login in graphical mode, before the password request, gdm try to access to the user home directory, which is located on a remote file server and accessible by NFS with an automount. But a network firewall blocks the access, because no authentication is done at this time in the Active Directory (an agent on the AD server send to the firewall the authentications).

So the field "Password" appears after a time greater than one minute. To reduce this time we added the option "MOUNT_WAIT=5" in the file "/etc/sysconfig/autofs", so the delay before the field "Password" appears is reduced to 10 seconds(autofs try 2 access).
After the user entered his password a window is displayed at the upper left corner of the monitor with the message "kstartupconfig4 does not exist or fails ...".
      -> autofs doesn't success to mount the home directory. It remains in a bad state and user have to restart it.
In console mode, the problem is not present. The user enters his login and password, then he's connected and its home directory is correctly mounted. When the autofs try to mount its home directory the user is already correctly authenticated in the AD and the firewall authorized the mount.
With a local user the problem is not present either, because the authentication and the home directory are local at the machine. Even if the home directory is shared via NFS.

The behaviour started with RHEL6.5 and is still present in latest version of gdm package available in RHEL6.8. When we downgrade only the rpm gdm and gdm-libs with the version 2.30.4-39.el6 of RHEL 6.4, the problem disappears. When the user enters his login, the password request is displayed immediately then he's connected and its home directory is correctly automounted.

Version-Release number of selected component (if applicable):

How reproducible:
Always on customer side

Actual results:
GDM is trying to access user's home which is located in network behind the firewall without completing the authentication process.

Expected results:
GDM should try to access user's home only after successful authentication.

Additional info:

The rules defined in firewall can't be modified which are blocking unauthenticated request to access user'e home. The behavior might have started due to BZ-795920

Comment 4 Chris Williams 2017-06-13 18:41:34 UTC
Red Hat Enterprise Linux 6 transitioned to the Production 3 Phase on May 10, 2017.  During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.
The official life cycle policy can be reviewed here:
This issue does not appear to meet the inclusion criteria for the Production Phase 3 and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification.  Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

Comment 24 errata-xmlrpc 2018-06-19 05:16:14 UTC
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.