search

389ds / 389-ds-base

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

aci with wildcard and macro not correctly evaluated #1472

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

The following aci

aci: (target="ldap:///cn=*/($dn),cn=services,cn=test,dc=example,dc=com")(version 3.0; acl "allow dding of own services"; allow (all) userdn = "ldap:///uid=($dn),ou=People,dc=example,dc=com";)

fails to match the resource cn=test/uid.xxxx,cn=services,cn=test,dc=example,dc=com

Need to investigate if this is expected behaviour or a bug

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2015-04-10 23:46:14

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1210852

389-ds-bot commented 4 years ago

Comment from mkosek at 2015-04-15 01:03:32

Ludwig planned to handle this one.

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2015-04-21 02:10:01

FYI: if it is adding another regex to ACL, it may cause a high CPU issue. We have an example which is showing the symptom...

389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2015-04-21 16:00:34

Replying to [comment:4 nhosoi]:

FYI: if it is adding another regex to ACL, it may cause a high CPU issue. We have an example which is showing the symptom...

no, I would not add another regex. For acis using only wildcards the evaluation uses regex, for acis containing a macro and a wildcard, it evaluates the wildcard directly, but makes assumptions on where the macro has to start, which misinterpretes some macro/wildcard combinations.

Do you have an example/test of high cpu usage with regex ? In my opinion using regex for our wildcard matching is overkill, it could probably be done by simpler algorithm using only strcmp.

389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2015-06-17 19:36:00

attachment 0001-Ticket-48141-aci-with-wildcard-and-macro-not-correct.patch

389-ds-bot commented 4 years ago

Comment from nhosoi (@nhosoi) at 2015-06-17 23:00:09

Your patch looks good to me.

Out of my curiosity... Now these cases are verified.

ndn:        cn=abc,ou=P,dc=example,dc=com
match_this: cn=*,($dn),dc=example,dc=com

ndn: cn=test/uid.xxxx,cn=services,cn=test,dc=example,dc=com
match_this: cn=*/($dn),cn=services,cn=test,dc=example,dc=com

I even don't know if there is such a requirement, but do we support multiple wildcards like this or not?

ndn: cn=abc,cn=test/uid.xxxx,cn=services,cn=test,dc=example,dc=com
match_this: cn=*,cn=*/($dn),cn=services,cn=test,dc=example,dc=com

Thanks!

389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2015-06-18 20:21:31

no, just one, there was no request and didn't want to hack more than needed. This would be a candidate for generalization, we could handle something like:

cn=,cn=/($dn1),cn=services,($dn2),cn=,dc=example,dc=com by matching cn=,cn=/,cn=services,,cn=,dc=example,dc=com

and returning an array m for the strings matching the * and then take m[2] and m[3] as value of macro components to match in the userdn

389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2015-06-18 20:56:56

committed to master

commit 4fbfc2e086c226e9a94b9afa8d1fc4efaab3a9aa

389-ds-bot commented 4 years ago

Comment from lkrispen (@elkris) at 2017-02-11 23:05:20

Metadata Update from @elkris: