#48141 aci with wildcard and macro not correctly evaluated
Closed: wontfix None Opened 7 years ago by lkrispen.

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

Ludwig planned to handle this one.

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

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.

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=

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:

by matching cn=

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

committed to master

commit 4fbfc2e

Metadata Update from @lkrispen:
- Issue assigned to lkrispen
- Issue set to the milestone:

5 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/1472

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)

2 years ago

Login to comment on this ticket.