Description of problem:
The "target" part of ACI can be used to specify, to which entry this ACI applies. If the target is not specified, the ACI applies to the entry containing the aci attribute and to the entries below it. Currently, it is possible to add non-existent target to ACI when it contains wildcards and macros and ACI is accepted by DS.
Steps to Reproduce: ldapmodify -h host -p portno -D "cn=directory manager" -w Secret123 <<EOF dn: cn=plugins,cn=config changetype: modify add: aci aci: (target="ldap:///cn=invalid,cn=plu*,cn=config")(version 3.0;acl "aci1";allow(search,read,write) userdn="ldap:///all";) EOF
Actual results: ACI is accepted.
Expected results: DS should indicate that ACI applies to non-existent entry.
Behaviour of wildcards:
(target="ldap:///uid=*,dc=example,dc=com") — Matches every entry in the example tree whose distinguished name contains the uid attribute. Thus, uid=fchen,ou=Engineering,dc=example,dc=com or uid=claire,ou=Engineering,ou=people,dc=example,dc=com would match, but uid=bjensen,dc=example,dc=com ou=Engineering,dc=example,dc=com would not.
A Possible Solution to handle wildcards:
According to the Administration guide, "You cannot use wildcards in the suffix part of a distinguished name. That is, if your directory uses the suffixes c=US and c=GB, then you cannot use (target="ldap:///dc=example,c=") as a target to reference both suffixes. Neither can you use a target such as uid=bjensen,dc=.com."
Currently, the directory server allows wildcards in suffixes. This problem might need to be fixed first before creating a fix for this ticket.
Probably, we could do something like this ... {{{ 1. get a target from aci. (assume it contains wildcards) 2. if it provides a base dn (e.g., <attr>=,ou=A,dc=B,dc=com), we could search using the base dn (ou=A,dc=B,dc=com in this example). Otherwise, search usign the base dn the aci belongs to. As of the search filter, you could use the leaf rdn of the target DN (<attr>= in this example). 3. get the DNs from the search results. 4-1. If the wildcard appears in the leaf rdn, the search result set can be used to validate the target. 4-2. If the wildcard appears in the middle (e.g., <attr1>=X,<attr2>=,<attr3>=Y,<attr4>=,<suffix>), replace "" with "." and use the regular expression library (PCRE) to check the matches. }}}
Comment by Ludwig:
would not fix, other users may rely on allowing targets for not yet existing entries, could be included in an ACL eval utility. part about wildcards in suffixes is valid
Metadata Update from @nhosoi: - Issue set to the milestone: 1.3.4 backlog
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/796
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: Invalid)
Login to comment on this ticket.