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

[Ludwig Krispenz]

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))"
you don't have 5 OR components, you have only 2, the second one is an 
AND with 4 components,
> 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.
>
>
>
> 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.
>

-- 
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander