Bug 985475

Summary: newgrp contains NIS related patches introducing full group scan in LDAP
Product: Red Hat Enterprise Linux 5 Reporter: Ron van der Wees <rvdwees>
Component: shadow-utilsAssignee: Tomas Mraz <tmraz>
Status: CLOSED ERRATA QA Contact: Dalibor Pospíšil <dapospis>
Severity: high Docs Contact:
Priority: high    
Version: 5.9CC: dapospis, ksrot, pvrabec, rvdwees, tmraz
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: shadow-utils-4.0.17-22.el5 Doc Type: Bug Fix
Doc Text:
Due to the previously added support for the split groups, the newgrp command searched all groups on the system for a given GID. This behavior could cause high network traffic on systems pulling user and group information from a Lightweight Directory Access Protocol (LDAP) server. The underlying source code has been modified, so that this exhaustive search is not performed if the user is a member of a group whose name is specified with newgrp.
 Story Points: ---
Clone Of:
: 993049 1096275 (view as bug list) Environment:
Last Closed: 2014-09-16 00:25:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 993049, 1049888, 1096275    
Attachments:
Description Flags
tcpdump showing the actual behavour
none
tcpdump showing the expected behaviour
none
Customer provided patch reverting change none

Description Ron van der Wees 2013-07-17 15:05:33 UTC 
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.
  >            */
Comment 1 Ron van der Wees 2013-07-17 15:15:48 UTC 
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.
Comment 2 Ron van der Wees 2013-07-17 15:20:17 UTC 
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)
Comment 3 Ron van der Wees 2013-07-17 15:25:14 UTC 
Created attachment 774824 [details]
Customer provided patch reverting change

The tcpdump created in comment #2 was collected after applying this patch.
Comment 4 Tomas Mraz 2013-08-05 14:07:53 UTC 
Unfortunately we cannot just simply revert the patch as this would break the splitted group feature.
Comment 6 Tomas Mraz 2013-12-16 11:13:23 UTC 
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.
Comment 7 Tomas Mraz 2013-12-16 11:13:51 UTC 
Would the solution above be sufficient?
Comment 8 RHEL Program Management 2014-01-22 16:29:44 UTC 
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.
Comment 22 errata-xmlrpc 2014-09-16 00:25:06 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.

http://rhn.redhat.com/errata/RHBA-2014-1217.html