#47922 dynamically added macro aci is not evaluated on the fly
Closed: wontfix None Opened 7 years ago by nhosoi.

This is a reguression.

sample aci>
dn: <SUFFIX>
aci: (target="ldap:///ou=People, ($dn), <SUFFIX>") (targetattr!="userPassword")(targetfilter=(objectClass=nsManagedPerson)) (version 3.0; acl "Admin access to all users in this and lower domains"; allow (write,read,search) groupdn="ldap:///cn=Domain Administrators, ou=Groups, [$dn], <SUFFIX>";)

UserA in the groupdn fails to modify the attributes of UserB which has "objectClass: nsManagedPerson" and under ou=People,($dn),<SUFFIX>. Both UserA and UserB share the same $dn.

The modify attempts returns Insufficient access.
ldap_modify: Insufficient access
ldap_modify: additional info: Insufficient 'write' privilege to the 'sn' attribute of entry 'uid=UserB,ou=people,($dn),<SUFFIX>'.

Restarting the server solves this problem and UserA is allowed to modify UserB's attributes.


I don't think we should change from case sensitive to case insensitive matching for everything. I think for keywords such as USERDN etc., we should keep those case sensitive. I don't want to get into a situation where we allow userdn, Userdn, UsErDn, and so on, and then have people depending on that behavior, have to update the docs, etc. I would rather keep all keywords case sensitive if they are currently case sensitive. Same with acl_strstr - should remain case sensitive.

{{{
aci_item->aci_macro->match_this = slapi_create_dn_string("%s", value);
if (NULL == aci_item->aci_macro->match_this) {
}}}
If the DN normalization fails, do we log an error somewhere saying that the given DN string is not valid and could not be normalized?

git patch file (master) -- revised following the comments by Rich (Thank you!!)
0001-Ticket-47922-dynamically-added-macro-aci-is-not-eval.2.patch

Reviewed by Ludwig and Rich (Thank you!!)

Pushed to master:
c7a78f4..07c1bc2 master -> master
commit 07c1bc2

Pushed to 389-ds-base-1.3.3:
90939dc..c6b397c 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit c6b397c

Pushed to 389-ds-base-1.3.2:
78feffc..7b39456 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 7b39456

Metadata Update from @nhosoi:
- Issue assigned to nhosoi
- Issue set to the milestone: 1.3.3 - 10/31 (October)

4 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/1253

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)

a year ago

Login to comment on this ticket.

Metadata