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:
We are seeing a number of customers who use Winbind authentication with Active Directory having their sudo attempts take as long as a minute to complete. This is because of a getgrgid function that was added to sudo which enumerates all of the groups that a person is a member of, even if the group isn't listed in the sudoers files. It is common for Active Directory to have a forest of trusted domains and for users to be members of groups in several of the domains. The problem is that either because of the size of the AD forest or network conditions it can take a significant amount of time to get information from some of these domains and that makes sudo very slow.
Version-Release number of selected component (if applicable):
sudo-1.8.6p3-12.el6
How reproducible:
Need a large forest of Active Directory domains or a domain that is slow to respond.
Steps to Reproduce:
1.N/A
2.
3.
Actual results:
All of the groups a person belongs to are enumerated by sudo
Expected results:
Only the groups listed in sudoers file are enumerated by sudo or an option is added that prevents the enumeration of all of a user's groups.
The slowest piece of code seems to be this:
/*
* Resolve and store group names by ID.
*/
ngroups = 0;
for (i = 0; i < ngids; i++) {
if ((grp = sudo_getgrgid(gids[i])) != NULL) {
len = strlen(grp->gr_name) + 1;
if (cp - (char *)grlitem + len > total) {
total += len + GROUPNAME_LEN;
efree(grlitem);
sudo_gr_delref(grp);
goto again;
}
memcpy(cp, grp->gr_name, len);
grlist->groups[ngroups++] = cp;
cp += len;
sudo_gr_delref(grp);
}
}
grlist->ngroups = ngroups;
which is in the function make_grlist_item() which is called from sudo_get_grlist(). getgrouplist() isn't called in this case because the sudoers policy plugin gets a group ID vector from the frontend (sudo.c). Getting this ID vector is fast.
A call to sudo_getgrgid() takes ~7 seconds to complete. sudo_getgrgid is just a caching wrapper for getgrgid(), so the ~7 seconds are spent in getgrgid(). That's a glibc function...
Jan 29 16:39:02 sudo[28598] -> sudo_getgrgid @ ./pwutil.c:655
Jan 29 16:39:02 sudo[28598] -> rbfind @ ./redblack.c:273
Jan 29 16:39:02 sudo[28598] <- rbfind @ ./redblack.c:280 := (nil)
Jan 29 16:39:09 sudo[28598] -> make_gritem @ ./pwutil.c:474
Jan 29 16:39:09 sudo[28598] <- make_gritem @ ./pwutil.c:524 := 0x7fcffb212f10
Jan 29 16:39:09 sudo[28598] -> rbinsert @ ./redblack.c:181
Jan 29 16:39:09 sudo[28598] <- rbinsert @ ./redblack.c:261 := (nil)
Jan 29 16:39:09 sudo[28598] <- sudo_getgrgid @ ./pwutil.c:681 := 0x7fcffb212f28
So even if I would implement some kind of on-demand-only resolving of group IDs, then for complex sudoers policies, such an optimization would have any efect as probably the majority of the groups would have to be resolved anyway.
I could try to hack some draft implementation and provide a test rpm. If one would use only gids in the sudoers rules, then that would improve the performance significantly. However, if there's no way how to make getgrgid faster then even for 3 group lookups it would take ~21 seconds, which is already quite bad from the user experience POV.
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://rhn.redhat.com/errata/RHBA-2016-0853.html