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