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): shadow-utils-4.0.17-21.el5 How reproducible: Always 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' Actual results: The network trace shows a LDAP search on the group directory with wholeSubTree and filter (objectClass=posixGroup) which return all 1500+ groups. Expected results: An LDAP search to the specific group with filter (&(objectClass=posixGroup)(cn=blah11502)) Additional info: * 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: http://comments.gmane.org/gmane.linux.pld.shadow.general/96 * 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 a release.
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. http://rhn.redhat.com/errata/RHBA-2014-1217.html