On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz wrote: > On 10/09/2014 04:27 PM, Simo Sorce wrote: > > On Thu, 09 Oct 2014 16:06:06 +0200 > > Ludwig Krispenz <lkris...@redhat.com> wrote: > > > >> On 10/09/2014 03:13 PM, Simo Sorce wrote: > >>> 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 ?
This is the ldif I used: dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com changetype: add objectClass: top objectClass: ipaToken objectClass: ipaTokenHOTP ipatokenUniqueID: autogenerate ipatokenOTPalgorithm: sha1 ipatokenOTPdigits: 6 ipatokenOTPkey: 00000000 ipatokenHOTPcounter: 0 ipatokenOwner: uid=otp,cn=users,cn=accounts,dc=example,dc=com managedBy: uid=otp,cn=users,cn=accounts,dc=example,dc=com > >>>> 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 ? > >> acis are always applied before the entry is sent to the client. the > >> control is added when the result is sent and for the postop control > >> it gets the POST_OP entry and checks read access to teh entry > > So you think the whole add was denied because the post-read couldn't > > read back the entry ? > as far as I understood Nathaniel, the add succeeded, only the control > was not returned > > Then fixing the read-related issue is all we need ? > you need an aci allowing to read the postop entry No. Issue #2 is unrelated to issue #1. In issue #2, the add itself fails. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
