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
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1210852
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]:
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.
attachment 0001-Ticket-48141-aci-with-wildcard-and-macro-not-correct.patch
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!
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
committed to master
commit 4fbfc2e
Metadata Update from @lkrispen: - Issue assigned to lkrispen - Issue set to the milestone: 1.3.4.0
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.