Bug 229290 - Password management inefficient entry usage
Password management inefficient entry usage
Status: CLOSED DUPLICATE of bug 184130
Product: 389
Classification: Community
Component: Performance (Show other bugs)
1.0.4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Rich Megginson
Orla Hegarty
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-19 18:12 EST by Pete Rowley
Modified: 2008-08-11 19:50 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-02-19 18:50:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pete Rowley 2007-02-19 18:12:54 EST
Description of problem:
A call to check_account_lock() (providing a slapi_entry) goes on to check
password expiry etc. with a call to new_passwdPolicy() passing in the DN of the
entry. new_passwdPolicy() then searches the db for the entry (that we already
have). This occurs in the bind code path so any optimization here would be good.
 There should be a way to pass in the entry to avoid the search.

new_passwdPolicy() seems to get called a lot in the password management code,
and there look to be other places that might be able to optimize out the search.

new_passwdPolicy() also has this comment
/*  If we're doing an add, COS does not apply yet so we check
                        parents for the pwdpolicysubentry.  We look only for virtual
                        attributes, because real ones are for single-target
policy. */

I'm not sure why this would be true - if an entry could be passed in in from the
add code this shouldn't be an issue I think, and the whole policy searching
algorithm could be ripped out and rely on COS for adds too (might be an issue
with regards to whether the add op has succeeded yet or something).

Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:
1. Write code to call check_account_lock()
2.
3.
  
Actual results:

Slower binds

Expected results:

Faster binds

Additional info:
Comment 1 Rich Megginson 2007-02-19 18:50:20 EST

*** This bug has been marked as a duplicate of 184130 ***
Comment 2 Chandrasekar Kannan 2008-08-11 19:50:10 EDT
Bug already CLOSED. setting screened+ flag

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