Red Hat Bugzilla – Bug 985475
newgrp contains NIS related patches introducing full group scan in LDAP
Last modified: 2014-09-15 20:25:06 EDT
Description of problem:
Running newgrp with LDAP as the group source in /etc/nsswitch.conf, causes the
client to retrieve all groups from the LDAP server. This introduces a delay
before newgrp returns the prompt to the user.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Setup an LDAP server with rfc2307bis schema (i.e. IPA Server)
2. Create 1500 groups in LDAP
3. Create one more group named 'blah11502' in LDAP
4. Create 'rvdwees10016' user in LDAP
5. Make 'rvdwees10016' member of 'blah11502'
6. Setup RHEL5.9 LDAP client with LDAP as the user and group source in nsswitch.conf
7. Set the following LDAP directives in /etc/ldap.conf
> nss_schema rfc2307bis
> nss_map_attribute uniqueMember member
8. Login in on the RHEL5.9 client as 'rvdwees10016'
9. run 'newgp blah11502'
The network trace shows a LDAP search on the group directory with wholeSubTree
and filter (objectClass=posixGroup) which return all 1500+ groups.
An LDAP search to the specific group with filter
* The full group scan has been introduced in newgrp to handle multiple group
entries with same GID to overcome the NIS group line length limitation.
This NIS related patch has been introduced in:
* From the shadow-utils Changelog:
> * For splitted groups (due to limitations of NIS), check all
> * groups of the same GID like the requested group for
> * membership of the current user.
Created attachment 774818 [details]
tcpdump showing the actual behavour
I'm attaching a tcpdump showing the actual behavour of newgrp retreiving all groups from LDAP. See frame 59.
Created attachment 774820 [details]
tcpdump showing the expected behaviour
I'm attaching a tcpdump showing the expected behavour of newgrp retreiving only the specific group. See frame 23.
(capture collected after rebuilding shadow-utils packages reverting the patch from http://comments.gmane.org/gmane.linux.pld.shadow.general/96)
Created attachment 774824 [details]
Customer provided patch reverting change
The tcpdump created in comment #2 was collected after applying this patch.
Unfortunately we cannot just simply revert the patch as this would break the splitted group feature.
We could skip the full group list retrieval if the user is found as a member of the group in the group returned by getgrnam.
Would the solution above be sufficient?
This request was evaluated by Red Hat Product Management for inclusion
in a Red Hat Enterprise Linux release. Product Management has
requested further review of this request by Red Hat Engineering, for
potential inclusion in a Red Hat Enterprise Linux release for currently
deployed products. This request is not yet committed for inclusion in
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.