Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
The pam_access.so module reads access rules from the access.conf file.
When parsing each whitespace-separated strings in the user/group field in access.conf, pam_access checks for user@host patterns and @netgroup patterns before checking whether the first and last characters are '(' and ')', respectively.
This is an error, for multiple reasons.
First, the access.conf(5) man page states:
> To differentiate user entries from group entries, group entries should be
> written with brackets, e.g. (group).
This implies that using (group) overrides any other interpretation of the string "group" except a group name, but the behavior of the code does not honor this override.
But more importantly, it makes it IMPOSSIBLE to specify a group that contains an '@' character. E.g.:
+ : (linux-managers) : ALL
Because the parsing checks for '@' characters before looking for the '(group)' override, the '(linux-managers)' string is parsed as a user@hostname, instead of as a group:
pam_access(sshd:account): login_access: user=someuser, from=somehost.example.org, file=/etc/security/access.conf
pam_access(sshd:account): line 16: + : (linux-managers) : ALL
pam_access(sshd:account): list_match: list= (linux-managers) , item=someuser
pam_access(sshd:account): user_match: tok=(linux-managers), item=someuser
pam_access(sshd:account): user_match: tok=(linux-managers, item=someuser
pam_access(sshd:account): string_match: tok=(linux-managers, item=someuser
pam_access(sshd:account): user_match=0, "someuser"
Not being able to use '@' characters in group names breaks sites that are using sssd(8) and use the sss database for user and group lookups. While sites that use only a single domain can leave off the @domain part, in the case where sssd(8) is using multiple domains, users and groups *MUST* be fully-qualified as user@domain and group@domain, respectively, to disambiguate which domain is being referred to.
Fortunately, the fix for this bug is very simple: change the user_match() function in modules/pam_access/pam_access.c to test for the '(group)' construct first, before attempting to split on '@' characters. I'll attach a patch momentarily.
Version-Release number of selected component (if applicable):
pam-1.1.8-12.el7_1.1.x86_64
How reproducible:
On an sssd-enabled system, attempt to grant access via a fully-qualified group@domain entry in /etc/security/access.conf.
Created attachment 1182636[details]
correct behavior of user_match() to honor (group) constructs
I think the best way to address this is to check for a '(group)' construct first, before attempting to parse for '@' characters.
Cross-filed as a support case.
(Sorry about the dupe—Bugzilla gave me an internal server error when I first tried to submit the bug, and I didn't think to check whether it actually succeeded despite the error.)
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.
https://access.redhat.com/errata/RHBA-2018:0718
Description of problem: The pam_access.so module reads access rules from the access.conf file. When parsing each whitespace-separated strings in the user/group field in access.conf, pam_access checks for user@host patterns and @netgroup patterns before checking whether the first and last characters are '(' and ')', respectively. This is an error, for multiple reasons. First, the access.conf(5) man page states: > To differentiate user entries from group entries, group entries should be > written with brackets, e.g. (group). This implies that using (group) overrides any other interpretation of the string "group" except a group name, but the behavior of the code does not honor this override. But more importantly, it makes it IMPOSSIBLE to specify a group that contains an '@' character. E.g.: + : (linux-managers) : ALL Because the parsing checks for '@' characters before looking for the '(group)' override, the '(linux-managers)' string is parsed as a user@hostname, instead of as a group: pam_access(sshd:account): login_access: user=someuser, from=somehost.example.org, file=/etc/security/access.conf pam_access(sshd:account): line 16: + : (linux-managers) : ALL pam_access(sshd:account): list_match: list= (linux-managers) , item=someuser pam_access(sshd:account): user_match: tok=(linux-managers), item=someuser pam_access(sshd:account): user_match: tok=(linux-managers, item=someuser pam_access(sshd:account): string_match: tok=(linux-managers, item=someuser pam_access(sshd:account): user_match=0, "someuser" Not being able to use '@' characters in group names breaks sites that are using sssd(8) and use the sss database for user and group lookups. While sites that use only a single domain can leave off the @domain part, in the case where sssd(8) is using multiple domains, users and groups *MUST* be fully-qualified as user@domain and group@domain, respectively, to disambiguate which domain is being referred to. Fortunately, the fix for this bug is very simple: change the user_match() function in modules/pam_access/pam_access.c to test for the '(group)' construct first, before attempting to split on '@' characters. I'll attach a patch momentarily. Version-Release number of selected component (if applicable): pam-1.1.8-12.el7_1.1.x86_64 How reproducible: On an sssd-enabled system, attempt to grant access via a fully-qualified group@domain entry in /etc/security/access.conf.