Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
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@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
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
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@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
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 06/16/2016 10:50 AM, Petr Spacek wrote:
On 16.6.2016 10:47, thierry bordaz 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@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.
Hi Petr,
In fact it is difficult to justify and identify which fix fixes this issue (I
suspect https://fedorahosted.org/389/ticket/48275 but not clear why it
participates).
in 1.3.5.6-1, it returns 11 entries. How many of them are
idnsServerConfigObject ? thanks theirry
Exactly one.
So "permission:System:Read DNS Servers Configuration" should grant
read/search rights only for this one.
There should be others ACI that grant you the access to the 10 others.
You may turn on ACI logging ("nsslapd-errorlog-level: 262272") to
identify which ACIs granted you this read/search access.
thanks
thierry
Petr^2 Spacek
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
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
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))" you don't have 5 OR components, you have only 2, the second one is an AND with 4 components, 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. 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
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
On 16.6.2016 10:47, thierry bordaz 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@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. > Hi Petr, > > In fact it is difficult to justify and identify which fix fixes this issue (I > suspect https://fedorahosted.org/389/ticket/48275 but not clear why it > participates). > > in 1.3.5.6-1, it returns 11 entries. How many of them are > idnsServerConfigObject ? thanks theirry Exactly one. Petr^2 Spacek >> 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 >>
Re: [Freeipa-devel] beware of 389-ds-base-1.3.5.4-1.fc24.x86_64: weird filter/ACI evaluation
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. Hi Petr, In fact it is difficult to justify and identify which fix fixes this issue (I suspect https://fedorahosted.org/389/ticket/48275 but not clear why it participates). in 1.3.5.6-1, it returns 11 entries. How many of them are idnsServerConfigObject ? thanks theirry 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.
