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

Thu Jun 16 09:47:32 UTC 2016

On 16.6.2016 11:34, Ludwig Krispenz wrote:
> 
> On 06/16/2016 11:23 AM, Ludwig Krispenz 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.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
> sorry, I now got it, I missed a closing ")" for teh AND :-(
> 
> but I think now it makes sense: for the first search, access to the
> idnsServerId attribute is only granted to the idnsServerConfigObject object
> and only this is returned because for teh other entries with other
> objectclasses we don't have access to it and we did require it.
> With the fix (rfe) this is handled more client friendly

Okay, so we need to bump Requries: in FreeIPA to newer DS to make sure it
actually works.

I will send a patch.

Thank you for your time guys!

Petr^2 Spacek

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