Bug 1417219 - Prevent gdm to access user's home without completing the authentication process.
Summary: Prevent gdm to access user's home without completing the authentication process.
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: gdm
Version: 6.5
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: Desktop QE
Depends On:
Blocks: 1461138 1492868
TreeView+ depends on / blocked
Reported: 2017-01-27 15:03 UTC by amit yadav
Modified: 2021-09-09 12:05 UTC (History)
6 users (show)

Fixed In Version: gdm-2.30.4-69.el6
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-06-19 05:16:14 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:1888 0 None None None 2018-06-19 05:16:23 UTC

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.


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