389-ds-base

Clone
Source Code
GIT

#48234 "matching rules" in ACI's "bind rules not fully evaluated
Closed: wontfix None Opened 9 years ago by rmeggins.

Closed: wontfix
Reopen Issue

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 6): Bug 1233926

Please note that this Bug is private and may not be accessible as it contains confidential Red Hat customer information.

Description of problem:

related to salesforce case number 01287227

and could be related to
bz 1160902 - search, matching rules and filter error "unsupported type 0xA9"


We seem to support "matching rules" in ACI's "bind rules", but cannot get that
feature to work as expected, the filters that work in some ldapsearch do not
when applied to ACIs, the ACI seem to always be granted.

The administration guide chapter
13.4 .1. Bind Rule Syntax
Table 13.3. LDIF Bind Rule Keywords

mentions a general userdn form with
ldap:///suffix??scope?(filter)

but using a matching rule in the form of
userdn = "ldap:///dc=example,dc=com??sub?(&(cn=admin)(ou:dn:=outest))"
does not seem to be evaluated

same thing with targetfilter

debug example:
[18/Jun/2015:15:06:15 -0700] NSACLPlugin - conn=6 op=1 (main): Allow read on
entry(uid=guest21,ou=people,dc=example,dc=com).attr(telephoneNumber) to
cn=admin,ou=outest,ou=ou1,dc=example,dc=com: cached allow by aci(2)

we need to find a workaround or attempt to fix if this is a defect.


Version-Release number of selected component (if applicable):

Red Hat Enterprise Linux Server release 6.6 (Santiago)
Linux m1.example.com 2.6.32-504.12.2.el6.x86_64 #1 SMP Sun Feb 1 12:14:02 EST
2015 x86_64 x86_64 x86_64 GNU/Linux
redhat-ds-9.1.0-1.el6.x86_64
389-ds-base-1.2.11.15-50.el6_6.x86_64


How reproducible:
consistently, if the test scenario makes sense with the filter used in the ACI.


Steps to Reproduce:
1. have some LDIF to create
dn:                    ou=ou1,dc=example,dc=com
dn:          ou=outest,ou=ou1,dc=example,dc=com
dn: cn=admin,ou=outest,ou=ou1,dc=example,dc=com
dn:                    ou=ou2,dc=example,dc=com
dn:          ou=outest,ou=ou2,dc=example,dc=com
dn: cn=admin,ou=outest,ou=ou2,dc=example,dc=com

2. as a simple test, I want to deny all the cn=admin in any ou:

aci: (targetattr = "telephoneNumber") (target = "ldap:///dc=example,dc=com")
(version 3.0;acl "admin-tel-matching-rule-outest";deny (all)(userdn =
"ldap:///dc=example,dc=com??sub?(&(cn=admin)(ou:dn:=outest))");)

3. the effective rights do not seem correct:

ldapsearch -LLLx -D "cn=directory manager" -w password -b dc=example,dc=com -s
sub -E
'!1.3.6.1.4.1.42.2.27.9.5.2=:dn:cn=admin,ou=outest,ou=ou1,dc=example,dc=com'
uid=guest21 telephoneNumber
dn: uid=guest21,ou=people,dc=example,dc=com
telephoneNumber: +1 111 222 3333
entryLevelRights: v
attributeLevelRights: telephoneNumber:rsc

4. and I was expecting no telephoneNumber attribute value when binding as a
cn=admin:

ldapsearch -LLLx -D cn=admin,ou=outest,ou=ou1,dc=example,dc=com -w password -b
dc=example,dc=com -s sub uid=guest21 telephoneNumber
dn: uid=guest21,ou=people,dc=example,dc=com
telephoneNumber: +1 111 222 3333

the aci debug had:

[18/Jun/2015:15:06:15 -0700] NSACLPlugin - conn=6 op=1 (main): Allow read on
entry(uid=guest21,ou=people,dc=example,dc=com).attr(telephoneNumber) to
cn=admin,ou=outest,ou=ou1,dc=example,dc=com: cached allow by aci(2)


Actual results:

details, it not clear to me what happens when (&(cn=admin)(ou:dn:=outest)) was
evaluated:

nsslapd-errorlog-level: 16416
16384 + 32 * 128 = 16544
    * 32 ? Search filter processing.
    * 128 ? Access control list processing.
    * 16384 ? Default level of logging used for critical errors and other
messages that are always written to the error log; for example, server startup
messages. Messages at this level are always included in the error log,
regardless of the log level setting.


[18/Jun/2015:14:43:07 -0700] NSACLPlugin - Evaluating DENY aci(198) "
"admin-tel-matching-rule-outest""
[18/Jun/2015:14:43:07 -0700] - slapi_str2filter "objectclass=*"
[18/Jun/2015:14:43:07 -0700] - slapi_str2filter: default
[18/Jun/2015:14:43:07 -0700] - str2simple "objectclass=*"
[18/Jun/2015:14:43:07 -0700] index_subsys_assign_filter_decoders - before:
(objectClass=*)
[18/Jun/2015:14:43:07 -0700] index_subsys_assign_filter_decoders -  after:
(objectClass=*)
[18/Jun/2015:14:43:07 -0700] - slapi_filter_dup type 0x87
[18/Jun/2015:14:43:07 -0700] - => slapi_vattr_filter_test_ext
[18/Jun/2015:14:43:07 -0700] - => test_substring_filter
[18/Jun/2015:14:43:07 -0700] -     PRESENT
[18/Jun/2015:14:43:07 -0700] - <= slapi_vattr_filter_test 0
[18/Jun/2015:14:43:07 -0700] - slapi_filter_free type 0x87
[18/Jun/2015:14:43:07 -0700] - slapi_filter_free type 0x87
[18/Jun/2015:14:43:07 -0700] - slapi_str2filter "(&(cn=admin)(ou:dn:=outest))"
[18/Jun/2015:14:43:07 -0700] - slapi_str2filter: AND
[18/Jun/2015:14:43:07 -0700] - str2list "(cn=admin)(ou:dn:=outest)"
[18/Jun/2015:14:43:07 -0700] - slapi_str2filter "(cn=admin)"
[18/Jun/2015:14:43:07 -0700] - slapi_str2filter: simple
[18/Jun/2015:14:43:07 -0700] - str2simple "cn=admin"
[18/Jun/2015:14:43:07 -0700] - slapi_str2filter "(ou:dn:=outest)"
[18/Jun/2015:14:43:07 -0700] - slapi_str2filter: simple
[18/Jun/2015:14:43:07 -0700] - str2simple "ou:dn:=outest"
[18/Jun/2015:14:43:07 -0700] - => slapi_vattr_filter_test_ext
[18/Jun/2015:14:43:07 -0700] - => test_substring_filter
[18/Jun/2015:14:43:07 -0700] -     AND
[18/Jun/2015:14:43:07 -0700] - => vattr_test_filter_list
[18/Jun/2015:14:43:07 -0700] - => slapi_vattr_filter_test_ext
[18/Jun/2015:14:43:07 -0700] - => test_substring_filter
[18/Jun/2015:14:43:07 -0700] -     EQUALITY
[18/Jun/2015:14:43:07 -0700] - => test_ava_filter
[18/Jun/2015:14:43:07 -0700] - => plugin_call_syntax_filter_ava cn=admin
[18/Jun/2015:14:43:07 -0700] - <= plugin_call_syntax_filter_ava 0
[18/Jun/2015:14:43:07 -0700] - <= test_ava_filter 0
[18/Jun/2015:14:43:07 -0700] - <= slapi_vattr_filter_test 0
[18/Jun/2015:14:43:07 -0700] - => slapi_vattr_filter_test_ext
[18/Jun/2015:14:43:07 -0700] - => test_substring_filter
[18/Jun/2015:14:43:07 -0700] -     EQUALITY
[18/Jun/2015:14:43:07 -0700] - => test_ava_filter
[18/Jun/2015:14:43:07 -0700] - <= test_ava_filter -1
[18/Jun/2015:14:43:07 -0700] - <= slapi_vattr_filter_test -1
[18/Jun/2015:14:43:07 -0700] - <= test_filter_list 1
[18/Jun/2015:14:43:07 -0700] - <= slapi_vattr_filter_test 1
[18/Jun/2015:14:43:07 -0700] - slapi_filter_free type 0xA0
[18/Jun/2015:14:43:07 -0700] - slapi_filter_free type 0xA3
[18/Jun/2015:14:43:07 -0700] - slapi_filter_free type 0xA3
[18/Jun/2015:14:43:07 -0700] NSACLPlugin - Processed:198 DENY handles Result:3
[18/Jun/2015:14:43:07 -0700] NSACLPlugin - 1. Evaluating ALLOW aci(188) "
"Enable anonymous access""
[18/Jun/2015:14:43:07 -0700] NSACLPlugin - Found READ ALLOW in cache
[18/Jun/2015:14:43:07 -0700] NSACLPlugin - conn=49 op=1 (main): Allow read on
entry(uid=guest21,ou=people,dc=example,dc=com).attr(telephoneNumber) to
cn=admin,ou=outest,ou=ou1,dc=example,dc=com: cached allow by aci(188)
[18/Jun/2015:14:43:07 -0700] - slapi_filter_free type 0xA3
[18/Jun/2015:14:43:40 -0700] - slapi_str2filter
"(|(objectclass=*)(objectclass=ldapsubentry))"


Expected results:

"matching rules" in LDAP search filters that return expected result to work the
same way when applied to ACI's "bind rules"



Additional info:

e-mail notes from Noriko / ldap-devel-list
"
it seems somehow this slapi_vattr_filter_test_ext_internal returns
not-matched...  Need to investigate it...

#0  slapi_vattr_filter_test_ext_internal (pb=0x7faf53ffeb10, e=0x7faf3800ded0,
f=0x7faf3800eb10, verify_access=0, only_check_access=0,
    access_check_done=0x7faf53ff2ad8) at ldap/servers/slapd/filterentry.c:959
#1  0x00007faf73c00d0c in slapi_vattr_filter_test_ext (pb=0x7faf53ffeb10,
e=0x7faf3800ded0, f=0x7faf3800eb10, verify_access=0, only_check_access=0)
    at ldap/servers/slapd/filterentry.c:825
#2  0x00007faf73c00ca1 in slapi_vattr_filter_test (pb=0x7faf53ffeb10,
e=0x7faf3800ded0, f=0x7faf3800eb10, verify_access=0)
    at ldap/servers/slapd/filterentry.c:788
#3  0x00007faf6aa41c03 in acllas__client_match_URL (aclpb=0x7faf7606a320,
n_clientdn=0x7faf3800ee70 "uid=tuser0,ou=outest,dc=example,dc=com",
    url=0x7faf38000fc0
"ldap:///dc=example,dc=com??sub?(&(uid=tuser0)(ou:dn:=outest))") at
ldap/servers/plugins/acl/acllas.c:3691


Document URL:

Section Number and Name:

Describe the issue:

Suggestions for improvement:

Additional information:


Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Note: need to check the matching rules in the filter (e.g., in CoS), as well.

Code looks good, and the tests pass for me.

ack,

Reviewed by William (Thanks!!)

Pushed to master:
a1545cd..59b8b05 master -> master
commit 32edbde
commit 59b8b05

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.5.5
7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1565

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
4 years ago

Log in to comment on this ticket.

Metadata
None
None
None
major
ack
RHCust
Powered by Pagure 5.14.1
Documentation • File an Issue • About • SSH Hostkey/Fingerprint
© Red Hat, Inc. and others.