[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))"
> 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.
I'm still not sure that I get your 5 and 4 OR filter searches, as in the 
example you provided there was also an AND involved, but there is a fix 
in 1.3.5.6. which makes a difference: 48275

Before we requested that in an OR filter the user has to have access to 
ALL attributes matched, so if you don't get results with 5 components, 
you could get results with 4. This was known, but much complained about. 
With the fix for 48275 we only request access to attributes contributing 
to the result set, components with attributes without access are ignored 
in bulding the result set.
This could explain different behaviour of 1.3.5.4 and .6
If you still think there are inconsistencies in 1.3.5.6 I would like to 
check it
>
> 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