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.



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.
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

--
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

Reply via email to