On Wed, 08 Oct 2014 17:46:01 -0400 Nathaniel McCallum <npmccal...@redhat.com> wrote:
> The background of this email is this bug: > https://fedorahosted.org/freeipa/ticket/4456 > > Attached are two patches which solve this issue for admin users (not > very helpful, I know). They depend on this fix in 389: > https://fedorahosted.org/389/ticket/47920 > > There are two outstanding issues: > > 1. 389 does not send the post read control for normal users. The > operation itself succeeds, but no control is sent. > > The relevant sections from the log are attached. 389 is denying access > to the following attributes (* = valid, ! = invalid): > ! objectClass > ! ipatokenOTPalgorithm > ! ipatokenOTPdigits > * ipatokenOTPkey > * ipatokenHOTPcounter > ! ipatokenOwner > ! managedBy > ! ipatokenUniqueID > > The ACIs allowing access to most of these attributes are here: > https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90 > > Note that I am able to query the entry just fine (including all the > above invalidly restricted attributes). Hence, I know the ACIs are > working just fine. > > Part of the strange thing is that in the post read control request, I > haven't indicated that I want *any* attributes returned (i.e. I want > just the DN). So I'm not sure why it is querying all the attributes. I > would suspect that the proper behavior would be to only check the ACIs > on attributes that will actually be returned. Can you show an example ldif ? I wonder if you are setting the owner ? > 2. The second patch (0002) modifies the ACI for normal user token > addition from this: > > aci: (target = > "ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX")(targetfilter = > "(objectClass=ipaToken)")(version 3.0; acl "Users can create > self-managed tokens"; allow (add) userattr = "ipatokenOwner#SELFDN" > and userattr = "managedBy#SELFDN";) > > To this: > > aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp, > $SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0; acl > "Users can create self-managed tokens"; allow (add) userattr = > "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";) > > The idea is to allow users to create tokens which will be expanded by > the UUID plugin. Unfortunately, after the UUID is expanded, the ACIs > are checked. Since the expanded UUID no longer matches the ACI, the > addition is denied. Is this truly the correct behavior? I would think > that the ACIs would be checked before the UUID plugin, not after. I would expect the same, can someone on the DS team comment ? Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel