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.
Bug 796307 - Simple Paged Search control needs to be used more sparingly
Summary: Simple Paged Search control needs to be used more sparingly
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-22 16:39 UTC by Stephen Gallagher
Modified: 2020-05-02 16:45 UTC (History)
4 users (show)

Fixed In Version: sssd-1.8.0-5.el6
Doc Type: Bug Fix
Doc Text:
No documentation required.
Clone Of:
Environment:
Last Closed: 2012-06-20 11:55:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 2244 0 None None None 2020-05-02 16:45:31 UTC
Red Hat Product Errata RHBA-2012:0747 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2012-06-19 19:31:43 UTC

Description Stephen Gallagher 2012-02-22 16:39:57 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/1202

We added support for the Simple Paged Search in ticket #658 and SSSD 1.5.8. When we did so, we chose to default to always requesting paged searches for all requests. However, it turns out that RFC 2696 does not mandate that the LDAP server supports more than one paging search at a time on the same connection. Some LDAP servers (notably 389 DS 1.2.9 and older) allow only a single paged search to be in progress on a request at one time. This results in receiving an error from LDAP that the server refuses to perform the operation. Once ticket #1201 is fixed, this will result in offline operation (right now it's misbehaving as if it received zero results). We need to avoid both of these events.

RFC 2696 does specify that if the result size being returned is smaller than the requested page size that the paging control '''should''' be ignored. This would mitigate the problem, but it appears that 389 DS also chooses to not ignore the control in this case.

In general, we need to find ways to minimize our usage of the paging control where available. I propose the following changes:

1. Add a boolean option to {{{ldap_generic_search_send()}}} to specify whether to use the paging control (when available).
1. Do not request the paging control when we expect a single-valued return from the request.
1. Always request the paging control for enumeration requests.
1. Serialize paging requests by maintaining a queue of lookups requiring paging and allow only one to operate at a time.{{{[1]}}}
1. If it can be reasonably determined that replies will never exceed 500 entries, also omit the paging control{{{[2]}}}

{{{[1]}}}: This will likely introduce apparent performance issues when performing initgroups() requests, since they will no longer be able to run in parallel. We must always assume that the user may belong to many groups.

{{{[2]}}}: I'm not 100% sure about this one. It's possible for a server to manually set its page size smaller than 500, though I doubt very many would do so. On the other hand, I can't come up with any ideas offhand for lookups of greater than a single entry that could not therefore result in a potentially-infinite set of results. So this may be a moot point.

Comment 1 Jenny Severance 2012-02-24 15:44:22 UTC
Please add steps to verify/reproduce this bug.

Comment 2 Stephen Gallagher 2012-02-24 16:00:50 UTC
Ok, I need to clarify that we reduced the scope of this bug upstream (and split it into two).

This bug is only for steps 1), 2) and 3) above; specifically, we will not request the paging control for requests that do not expect more than one result.


This is best tested with 389 DS <= 1.2.9.

Configure SSSD for id_provider = LDAP and then run multiple concurrent calls to 'getent passwd <username>' (with different users in each call. They need to be run in parallel.

Prior to this patch, some of those lookups would fail, and the sssd_DOMAIN.log would contain a message similar to "Error [53]: Server unwilling to perform" (that may not be the exact syntax). With this patch, all of the 'getent passwd <username>' calls should succeed.

Comment 4 Amith 2012-04-25 09:13:04 UTC
Tested and verified on sssd-1.8.0-22.el6.x86_64.

Verified the bug against both Openldap and 389-DS server. As part of this, multiple user lookups were conducted concurrently by scheduling them at the same time using "at" command. All the user lookups were successful and cached.

Comment 5 Stephen Gallagher 2012-06-12 13:37:21 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
No documentation required.

Comment 7 errata-xmlrpc 2012-06-20 11:55: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-2012-0747.html


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