Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 184130

Summary:	Internal Password Policy usage very inefficient
Product:	[Retired] 389	Reporter:	Rich Megginson <rmeggins>
Component:	Security - Password Policy	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Chandrasekar Kannan <ckannan>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.0	CC:	benl, nkinder
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	389-ds-base-1.3.0.0-1	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-12-18 19:48:52 UTC	Type:	---
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:	495079, 512820, 690319

Description Rich Megginson 2006-03-06 18:03:29 UTC

For a password modify operation (ldap modify or extop) we call
new_passwdPolicy/delete_passwdPolicy 4 or more times (if all password checking
is selected).  I think it would be much more efficient to just call
new_passwdPolicy once and stuff the policy object in the pblock, and have the
different cases use the one in the pblock if present.

This should work fine for all cases but the per user password policy case if
that policy is being set at the same time as the password is being modified.  In
that case, we need to be very careful about the order of applying the change.

Comment 1 Rich Megginson 2007-02-19 23:50:33 UTC

*** Bug 229290 has been marked as a duplicate of this bug. ***

Comment 2 Rich Megginson 2007-02-19 23:51:17 UTC

more from Pete:
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).

Comment 4 Rich Megginson 2009-01-12 18:31:36 UTC

Let's revisit this in 8.2 when we examine the password policy code

Comment 5 Rich Megginson 2009-04-09 16:52:14 UTC

This falls under the category of "expose password policy to plug-ins"

Comment 6 Martin Kosek 2012-01-04 13:49:40 UTC

Upstream ticket:
https://fedorahosted.org/389/ticket/147

Comment 7 Nathan Kinder 2013-12-18 19:48:52 UTC

This was fixed in 389-ds-base-1.3.0.0-1.