Bug 457951 - Sorted range search shouldn't be used when a DNA prefix is set
Sorted range search shouldn't be used when a DNA prefix is set
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Server - DNA Plug-in (Show other bugs)
1.1.1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
Depends On:
Blocks: 249650 FDS112
  Show dependency treegraph
 
Reported: 2008-08-05 14:24 EDT by Nathan Kinder
Modified: 2015-01-04 18:33 EST (History)
3 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:05:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CVS Diffs (11.78 KB, patch)
2008-08-05 14:28 EDT, Nathan Kinder
no flags Details | Diff
Revised Diffs (11.83 KB, patch)
2008-08-05 16:17 EDT, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Nathan Kinder 2008-08-05 14:24:28 EDT
The DNA plug-in uses a range search internally to locate the next free value within the managed range.  This works fine when the values are strictly integers, but the DNA plug-in supports a prefix to the integer portion of the value (such as "user1 - user1000").

When a prefix is defined, we should not use a range search to locate the next free value.  We should simply do an exact match search to see if the next value in the cached configuration entry is free.  If it is not free, we iterate through each value in the range until we either find a free value, or hit the end of the range.  This will typically perform fine, as the next value in the configuration entry should be free unless someone manually assigned it.  The worst case scenario is that we have to go through a large block of values that was manually assigned, which will be helped by an equality index.  Even so, this case should be rare.
Comment 1 Nathan Kinder 2008-08-05 14:28:23 EDT
Created attachment 313468 [details]
CVS Diffs

These changes implement the approach described in the previous comment.  For efficiency in the case that we have to go through a large block of manually assigned values, I wanted to reuse a previously allocated pblock instead of allocating one for each search.  This required me to export a new public SLAPI function that re-initializes a pblock so it can be reused.
Comment 2 Rich Megginson 2008-08-05 15:44:56 EDT
https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff#ldap/servers/plugins/dna/dna.c_sec1 - lines 864-880

You could use ldap_controls_free(ctrls) - it is ok to pass a NULL, and it will free all controls in the array e.g.
 ldap_controls_free(ctrls);
 ctrls = NULL;
instead of
 if (ctrls) {
   ldap_control_free(ctrls[0]);
   slapi_ch_free(&ctrls);
 }

https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff#ldap/servers/plugins/dna/dna.c_sec2 - line 917

Is it ok to call slapi_free_search_results_internal with no search results?
Comment 3 Nathan Kinder 2008-08-05 15:49:44 EDT
(In reply to comment #2)
> https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff#ldap/servers/plugins/dna/dna.c_sec1
> - lines 864-880
> 
> You could use ldap_controls_free(ctrls) - it is ok to pass a NULL, and it will
> free all controls in the array e.g.
>  ldap_controls_free(ctrls);
>  ctrls = NULL;
> instead of
>  if (ctrls) {
>    ldap_control_free(ctrls[0]);
>    slapi_ch_free(&ctrls);
>  }

I'll address this in a new set of diffs shortly.

> 
> https://bugzilla.redhat.com/attachment.cgi?id=313468&action=diff#ldap/servers/plugins/dna/dna.c_sec2
> - line 917
> 
> Is it ok to call slapi_free_search_results_internal with no search results?

Yes, this is safe.  The slapi_free_search_results_internal() function first checks if pb->pb_plugin_internal_search_op_entries and pb->pb_plugin_internal_search_op_referrals are NULL before attempting to free them.
Comment 4 Nathan Kinder 2008-08-05 16:17:48 EDT
Created attachment 313486 [details]
Revised Diffs
Comment 5 Nathan Kinder 2008-08-06 10:56:05 EDT
Checked into ldapserver (HEAD).  Thanks to Rich for his review!

Checking in ldap/servers/plugins/dna/dna.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/dna/dna.c,v  <--  dna.c
new revision: 1.8; previous revision: 1.7
done
Checking in ldap/servers/slapd/pblock.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/pblock.c,v  <--  pblock.c
new revision: 1.16; previous revision: 1.15
done
Checking in ldap/servers/slapd/slapi-plugin.h;
/cvs/dirsec/ldapserver/ldap/servers/slapd/slapi-plugin.h,v  <--  slapi-plugin.h
new revision: 1.28; previous revision: 1.27
done
Comment 6 Jenny Galipeau 2009-03-12 16:01:36 EDT
Would it suffice for verification if I added 1000 users using DNA to assign uid numbers that was configured with a prefix - (user1 user10 user100 user1000) and then verify their assigned uidNumbers?
Thanks
Comment 7 Nathan Kinder 2009-03-12 18:20:49 EDT
- Setup a range with a prefix for "user1" - "user100".

- Manually create 3 users explicitly specifying values of "user1", "user2", and  
  "user11" to bypass DNA.

- Create a new user and allow DNA to generate the value from the range.  Make 
  sure that the new user gets the "user3" value from the range.
Comment 8 Jenny Galipeau 2009-03-13 12:58:39 EDT
fix verified RHEL 4 - new automated acceptance test added to regress this bug - results:

DNA TEST BUG 457951: Sorted Range Search With DNA Prefix
Adding users and groups with manually defined uid and gid numbers 1,2, and 11
adding new entry cn=Posix User1,ou=People,o=dna.net

adding new entry cn=Posix User2,ou=People,o=dna.net

adding new entry cn=Posix User11,ou=People,o=dna.net

adding new entry cn=Group1,ou=Groups,o=dna.net

adding new entry cn=Group2,ou=Groups,o=dna.net

adding new entry cn=Group11,ou=Groups,o=dna.net

adding new entry cn=Posix User101,ou=People,o=dna.net

adding new entry cn=Posix User102,ou=People,o=dna.net

adding new entry cn=Posix User111,ou=People,o=dna.net

adding new entry cn=Group101,ou=Groups,o=dna.net

adding new entry cn=Group102,ou=Groups,o=dna.net

adding new entry cn=Group111,ou=Groups,o=dna.net

Add users and groups and let DNA assign uid and gid numbers - next 3
adding new entry cn=Posix User3,ou=People,o=dna.net

adding new entry cn=Group3,ou=Groups,o=dna.net

adding new entry cn=Posix User103,ou=People,o=dna.net

adding new entry cn=Group103,ou=Groups,o=dna.net

Verifying users added from server 1
Posix User1 is assigned expected uidNumber: user1
Posix User2 is assigned expected uidNumber: user2
Posix User3 is assigned expected uidNumber: user3
Posix User11 is assigned expected uidNumber: user11
Verifying users added from server 2
Posix User101 is assigned expected uidNumber: user101
Posix User102 is assigned expected uidNumber: user102
Posix User103 is assigned expected uidNumber: user103
Posix User111 is assigned expected uidNumber: user111
Verifying groups added from server 1
Group1 is  assigned expected gidNumber: group1
Group2 is  assigned expected gidNumber: group2
Group3 is  assigned expected gidNumber: group3
Group11 is  assigned expected gidNumber: group11
Verifying groups added from server 2
Group101 is  assigned expected gidNumber: group101
Group102 is  assigned expected gidNumber: group102
Group103 is  assigned expected gidNumber: group103
Group111 is  assigned expected gidNumber: group111
TestCaseResult dna_bug457951 PASS
Comment 9 Chandrasekar Kannan 2009-04-29 19:05:32 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html

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