[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openldap-bugs
Subject:    [Issue 8528] Incorrect results on replace op for olcAccess
From:       openldap-its () openldap ! org
Date:       2020-11-27 22:10:44
Message-ID: bug-8528-2-NkJFn1CuE9 () http ! bugs ! openldap ! org/
[Download RAW message or body]

https://bugs.openldap.org/show_bug.cgi?id=8528

Howard Chu <hyc@openldap.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #7 from Howard Chu <hyc@openldap.org> ---
(In reply to Quanah Gibson-Mount from comment #1)
> --On Friday, November 04, 2016 12:41 AM +0000 openldap-its@OpenLDAP.org 
> wrote:
> 
> Here's the full text, since the web form apparently ate it:
> 
> When doing a full replace on all values for olcAccess, things work 
> incorrectly if the values provided are not in numeric sorted order.  This 
> is problematic when using tools like ldapvi who do alphabetic sort.  It is 
> trivial to reproduce the problem using the following example LDIFs:
> 
> cat > replace_ordered.ldif <<EOF
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> replace: olcAccess
> olcAccess: {0}to dn.exact="cn=0" by * none
> olcAccess: {1}to dn.exact="cn=1" by * none
> olcAccess: {2}to dn.exact="cn=2" by * none
> olcAccess: {3}to dn.exact="cn=3" by * none
> olcAccess: {4}to dn.exact="cn=4" by * none
> olcAccess: {5}to dn.exact="cn=5" by * none
> olcAccess: {6}to dn.exact="cn=6" by * none
> olcAccess: {7}to dn.exact="cn=7" by * none
> -
> EOF
> 
> cat > replace_ordered_mixup.ldif <<EOF
> dn: olcDatabase={1}mdb,cn=config
> changetype: modify
> replace: olcAccess
> olcAccess: {7}to dn.exact="cn=7" by * none
> olcAccess: {1}to dn.exact="cn=1" by * none
> olcAccess: {4}to dn.exact="cn=4" by * none
> olcAccess: {3}to dn.exact="cn=3" by * none
> olcAccess: {5}to dn.exact="cn=5" by * none
> olcAccess: {0}to dn.exact="cn=0" by * none
> olcAccess: {6}to dn.exact="cn=6" by * none
> olcAccess: {2}to dn.exact="cn=2" by * none
> -
> EOF
> 
> With the initial config as:
> 
> olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * 
> none
> olcAccess: {1}to attrs=shadowLastChange by self write by * read
> olcAccess: {2}to * by * read
> 
> When the ordered version is done, the correct result occurs:
> 
> olcAccess: {0}to dn.exact="cn=0" by * none
> olcAccess: {1}to dn.exact="cn=1" by * none
> olcAccess: {2}to dn.exact="cn=2" by * none
> olcAccess: {3}to dn.exact="cn=3" by * none
> olcAccess: {4}to dn.exact="cn=4" by * none
> olcAccess: {5}to dn.exact="cn=5" by * none
> olcAccess: {6}to dn.exact="cn=6" by * none
> olcAccess: {7}to dn.exact="cn=7" by * none
> 
> However, when the unordered replaced is done, an incorrect result occurs:
> 
> olcAccess: {0}to dn.exact="cn=0" by * none
> olcAccess: {1}to dn.exact="cn=7" by * none
> olcAccess: {2}to dn.exact="cn=2" by * none
> olcAccess: {3}to dn.exact="cn=1" by * none
> olcAccess: {4}to dn.exact="cn=4" by * none
> olcAccess: {5}to dn.exact="cn=3" by * none
> olcAccess: {6}to dn.exact="cn=5" by * none
> olcAccess: {7}to dn.exact="cn=6" by * none
> 
> Since we are doing a replace of all values, it should not be trying to 
> reweight the operation. Instead, the values should just be numeric sorted 
> and then written out accordingly, so one ends up with the same result as in 
> the ordered case.

This ITS is invalid. The frontend is not trying to reweight the operation,
but you're giving it invalid input.

It processes each value in the order it was given. You put {7} first but at
that point in time, there aren't 7 values in the attribute, so it goes "at the
end".

The 2nd input is {1}, which gets put into the 2nd slot, so you have {7}, {1}.
The 3rd input is {4} but there are only 2 values, so it goes at the end in the
3rd slot.

The 4th input is {3} so it gets inserted into the 3rd slot and pushes the
previous value in the 3rd slot into the 4th slot.


The 5th input is {5} so it goes at the end.

The 6th input is {0} so it gets inserted into the 1st slot and pushes
everything else out by 1.

The 7th input is {6} so it goes at the end.

The 8th input is {2} so it gets inserted in the 3rd slot and pushes everything
else out by 1.


Closing this ITS.

-- 
You are receiving this mail because:
You are on the CC list for the issue.=
[prev in list] [next in list] [prev in thread] [next in thread]