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

[Petr Spacek]

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.

This would be a blocker for FreeIPA 4.4 because the old version totally breaks
bind-dyndb-ldap.

-- 
Petr^2 Spacek