Bug 457951

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.

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?

(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.

Created attachment 313486 [details]
Revised Diffs

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

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

- 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.

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

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