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....@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....@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....@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. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code