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.