Hi,
yes, the implemantation makes sense: you cannot base the decision to use
an aci on an attribute that does not yet exist.
But on the other hand I think your use case also makes sense, but if I
understand it correctly is what you want is:
- allow a user to modify or delete an entry only if the ipatokenowner
attr matches the user
- allow a user to add an entry only if it sets the ipatokenowner to
itself. This kind of restiction should be handled by the targattrfilter
part in the target definition, saying that only spefiic values can be
used for an attribute. Unfortunately this target clause cannnot handle
things like: "targattrfilters="add=ipatokenowner:USERDN" and I don't see
how easily this would be implemented.
Now, do we want to allow some "I know what I'm doing" flag or do we want
to relax the interpratation of userattr for adding entries, I don't
know, and we will not have a decision in this year, but I'd support your
request to handle it somehow. So could you create a ticket for an
enhancement ?
Regards,
Ludwig
On 12/20/2013 11:31 PM, Nathaniel McCallum wrote:
I'm working on this project: http://www.freeipa.org/page/V3/OTP
Users need to be able to create, edit and delete their own tokens. Each
token has an attribute: ipatokenOwner.
I attempted creating this ACL: (target =
"ldap:///ipatokenuniqueid=*,cn=otp,dc=example,dc=com";)(targetfilter =
"(objectClass=ipaToken)")(version 3.0; acl "token-add-delete"; allow
(add, delete) userattr = "ipatokenOwner#USERDN";)
After much debugging I found out this is impossible because of this:
https://git.fedorahosted.org/cgit/389/ds.git/tree/ldap/servers/plugins/acl/acllas.c#n1282
Now, in the general case, I can very much understand why this shouldn't
be allowed by default. What alternatives are there with the current
code? Would 389DS be willing to accept a patch to enable this (with a
I_KNOW_WHAT_I_AM_DOING flag)?
The general reason why this feature works in my case is that each object
created restricts the user, rather than granting new privileges. This
seems like a valid use case.
Nathaniel
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
