[Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation

[Petr Spacek]

On 16.6.2016 10:47, thierry bordaz wrote:
> On 06/16/2016 06:55 AM, Petr Spacek wrote:
>> Hello,
>>
>> TL;DR version:
>> Upgrade to 389-ds-base-1.3.5.6-1.fc24.
>>
>> I was facing weird filter/ACI evaluation with 389 DS
>> 389-ds-base-1.3.5.4-1.fc24.x86_64. Here is full story (written before I
>> realized that DS is old one ...):
>>
>>
>> Test
>> ====
>> First, let's try LDAP search with OR filter consisting of 5 components:
>>
>> [16/Jun/2016:06:05:18.145159021 +0200] conn=119 op=2 RESULT err=0 tag=97
>> nentries=0 etime=0
>> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat.com at dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
>>
>> [16/Jun/2016:06:05:18.145920002 +0200] conn=119 op=3 SRCH
>> base="cn=dns,dc=toplevel" scope=2
>> filter="(|(objectClass=idnsConfigObject)(&(objectClass=idnsServerConfigObject)(idnsServerId=vm-046.abc.idm.lab.eng.brq.redhat.com))(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
>>
>> attrs="objectClass"
>> [16/Jun/2016:06:05:18.149821586 +0200] conn=119 op=3 RESULT err=0 tag=101
>> nentries=1 etime=0
>> [16/Jun/2016:06:05:18.150433307 +0200] conn=119 op=4 UNBIND
>> [16/Jun/2016:06:05:18.150459102 +0200] conn=119 op=4 fd=108 closed - U1
>>
>> It returns 1 entry - the idnsServerConfigObject object.
> Hi Petr,
> 
> In fact it is difficult to justify and identify which fix fixes this issue (I
> suspect https://fedorahosted.org/389/ticket/48275 but not clear why it
> participates).
> 
> in 1.3.5.6-1, it returns 11 entries. How many of them are
> idnsServerConfigObject ? thanks theirry

Exactly one.

Petr^2 Spacek

>> Now let us re-try shortened filter containing only 4 OR components. I would
>> expect to get less entries but that is not the case:
>>
>> [16/Jun/2016:06:05:21.007494823 +0200] conn=120 fd=108 slot=108 SSL connection
>> from 2620:52:0:224e:21a:4aff:fe23:12d2 to 2620:52:0:224e:21a:4aff:fe23:12d2
>> [16/Jun/2016:06:05:21.022115576 +0200] conn=120 TLS1.2 128-bit AES
>> [16/Jun/2016:06:05:21.029902095 +0200] conn=120 op=0 BIND dn="" method=sasl
>> version=3 mech=GSSAPI
>> [16/Jun/2016:06:05:21.042047525 +0200] conn=120 op=0 RESULT err=14 tag=97
>> nentries=0 etime=0, SASL bind in progress
>> [16/Jun/2016:06:05:21.043007851 +0200] conn=120 op=1 BIND dn="" method=sasl
>> version=3 mech=GSSAPI
>> [16/Jun/2016:06:05:21.044811757 +0200] conn=120 op=1 RESULT err=14 tag=97
>> nentries=0 etime=0, SASL bind in progress
>> [16/Jun/2016:06:05:21.045183711 +0200] conn=120 op=2 BIND dn="" method=sasl
>> version=3 mech=GSSAPI
>> [16/Jun/2016:06:05:21.046395695 +0200] conn=120 op=2 RESULT err=0 tag=97
>> nentries=0 etime=0
>> dn="krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat.com at dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel"
>>
>> [16/Jun/2016:06:05:21.046947437 +0200] conn=120 op=3 SRCH
>> base="cn=dns,dc=toplevel" scope=2
>> filter="(|(objectClass=idnsConfigObject)(objectClass=idnsZone)(objectClass=idnsForwardZone)(objectClass=idnsRecord))"
>>
>> attrs="objectClass"
>> [16/Jun/2016:06:05:21.052008250 +0200] conn=120 op=3 RESULT err=0 tag=101
>> nentries=11 etime=0
>>
>> Huh? Now we got 11 entries.
>>
>>
>> When I do the first search as Directory Manager it returns all 12 matching
>> entries (which is expected number, at least according to my match-by-eye
>> algorithm :-)).
>>
>>
>> Schema
>> ======
>> idnsServerId attribute definition contains an equality specification:
>> ( 2.16.840.1.113730.3.8.5.31 NAME 'idnsServerId' DESC 'DNS server identifier'
>> EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
>> X-ORIGIN 'IPA v4.4' )
>>
>>
>> Indices
>> =======
>> The attribute itself is not indexed but that should not hurt I guess.
>>
>> Mere addition of equality index to the attribute did not help.
>>
>> Reindexing using
>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/applying-indexes.html#index-cn-tasks
>>
>> did not help either.
>>
>>
>>
>> ACI
>> ===
>> Relevant ACIs are:
>> (targetattr = "createtimestamp || entryusn || idnsforwarders ||
>> idnsforwardpolicy || idnsserverid || idnssoamname || idnssubstitutionvariable
>> || modifytimestamp || objectclass")(targetfilter =
>> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
>> Read DNS Servers Configuration";allow (compare,read,search) groupdn =
>> "ldap:///cn=System: Read DNS Servers
>> Configuration,cn=permissions,cn=pbac,dc=toplevel";)
>>
>> (targetattr = "idnsforwarders || idnsforwardpolicy || idnssoamname ||
>> idnssubstitutionvariable")(targetfilter =
>> "(objectclass=idnsServerConfigObject)")(version 3.0;acl "permission:System:
>> Modify DNS Servers Configuration";allow (write) groupdn = "ldap:///cn=System:
>> Modify DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel";)
>>
>>
>> BIND DN
>> krbprincipalname=dns/vm-046.abc.idm.lab.eng.brq.redhat.com at dom-046.abc.idm.lab.eng.brq.redhat.com,cn=services,cn=accounts,dc=toplevel
>>
>> is member of
>> cn=DNS Servers,cn=privileges,cn=pbac,dc=toplevel
>> which is member of
>> cn=System: Read DNS Servers Configuration,cn=permissions,cn=pbac,dc=toplevel
>>
>> so we should be all good.
>>
>>
>>
>> Now was totally confused and was looking for a bug in bind-dyndb-ldap until I
>> realized that DS is returning weird results... Upgrade to
>> 389-ds-base-1.3.5.6-1.fc24.x86_64 fixed that.
>>
>> This would be a blocker for FreeIPA 4.4 because the old version totally breaks
>> bind-dyndb-ldap.