STEPS TO REPRODUCE
That is not really the same test at all.
Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com -W -e postread=* <<EOF dn: ipatokenuniqueid=foo,cn=otp,dc=example,dc=com changetype: add objectClass: top objectClass: ipaToken objectClass: ipaTokenHOTP ipatokenUniqueID: foo ipatokenOTPalgorithm: sha1 ipatokenOTPdigits: 6 ipatokenOTPkey: 00000000 ipatokenHOTPcounter: 0 ipatokenOwner: uid=admin,cn=users,cn=accounts,dc=example,dc=com managedBy: uid=admin,cn=users,cn=accounts,dc=example,dc=com EOF
Create a regular user named 'otp'
EXPECTED RESULTS Two tokens should be added and the replies (#2 and #4) should contain the post read control.
RESULTS #2 will add the token and return the post read control. #4 will add the token, but will NOT return the post read control.
The problem is that the aci code when testing access to the entry still has the operation type as ADD, and for ADDs the USERDN aci is not accepted. That is why in ticket 47653 the SELFDN keyword was implemented.
When I change the aci to: aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#SELFDN" or userattr = "managedBy#SELFDN";)
and add as ordinary user gets the control.
Is this an acceptable workaround ?
formatting was terrible, new attempt: {{{ aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || description || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNotBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSerial || ipatokenOwner")(version 3.0; acl "Users/managers can read basic token info"; allow (read, search, compare) userattr = "ipatokenOwner#SELFDN" or userattr = "managedBy#SELFDN";) }}}
Works for me!
Metadata Update from @lkrispen: - Issue set to the milestone: N/A
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/1255
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.