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.
ACL log messages acl.log.txt
git patch file (master) 0001-Ticket-47922-dynamically-added-macro-aci-is-not-eval.patch
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1151287
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)
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.
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.