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

Thu Jun 16 09:34:20 UTC 2016

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