search

389ds / 389-ds-base

The enterprise-class Open Source LDAP server for Linux
https://www.port389.org/
Other
210 stars 89 forks source link

"matching rules" in ACI's "bind rules not fully evaluated #1565

Closed 389-ds-bot closed 4 years ago

389-ds-bot commented 4 years ago

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48234

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:
389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2016-01-08 01:17:53

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

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2016-06-11 07:34:36

git patch file (master) 0001-Ticket-48234-matching-rules-in-ACI-s-bind-rules-not-.patch

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2016-06-11 07:34:59

git patch file (master) -- CI test 0002-Ticket-48234-CI-test-test-case-for-ticket-48234.patch

389-ds-bot commented 4 years ago

Comment from firstyear (@Firstyear) at 2016-06-14 06:19:13

Code looks good, and the tests pass for me.

ack,

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2016-06-14 22:52:39

Reviewed by William (Thanks!!)

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

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2017-02-11 23:03:57

Metadata Update from @nhosoi: