This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 985475 - newgrp contains NIS related patches introducing full group scan in LDAP
newgrp contains NIS related patches introducing full group scan in LDAP
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: shadow-utils (Show other bugs)
5.9
All Linux
high Severity high
: rc
: ---
Assigned To: Tomas Mraz
Dalibor Pospíšil
:
Depends On:
Blocks: 1049888 993049 1096275
  Show dependency treegraph
 
Reported: 2013-07-17 11:05 EDT by Ron van der Wees
Modified: 2014-09-15 20:25 EDT (History)
5 users (show)

See Also:
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-15 20:25:06 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tcpdump showing the actual behavour (1.84 MB, application/vnd.tcpdump.pcap)
2013-07-17 11:15 EDT, Ron van der Wees
no flags Details
tcpdump showing the expected behaviour (14.84 KB, application/vnd.tcpdump.pcap)
2013-07-17 11:20 EDT, Ron van der Wees
no flags Details
Customer provided patch reverting change (1.54 KB, patch)
2013-07-17 11:25 EDT, Ron van der Wees
no flags Details | Diff

  None (edit)
Description Ron van der Wees 2013-07-17 11:05:33 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):
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 11:15:48 EDT
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 11:20:17 EDT
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 11:25:14 EDT
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 10:07:53 EDT
Unfortunately we cannot just simply revert the patch as this would break the splitted group feature.
Comment 6 Tomas Mraz 2013-12-16 06:13:23 EST
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 06:13:51 EST
Would the solution above be sufficient?
Comment 8 RHEL Product and Program Management 2014-01-22 11:29:44 EST
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-15 20:25:06 EDT
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

Note You need to log in before you can comment on or make changes to this bug.