On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: > On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: > > On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: > >> On 10/08/2014 11:46 PM, Nathaniel McCallum 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 > >> Hello Nathaniel, > >> > >> The post read control needs access to the modified entry to > >> return it. > >> This access is granted at the condition, the binddn can access > >> attributes. > > Agreed and understood. > > > >> My understanding is that the target entry is > >> > >> ipatokenuniqueid=52001946-4f2d-11e4-9127-7831c1d63a78,cn=otp,dc=example,dc=com > >> and the binddn "uid=otp,cn=users,cn=accounts,dc=example,dc=com". > > Correct. > > > >> The only ACI I found that match this target is: > >> 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#USERDN" or > >> userattr = "managedBy#USERDN";) > > Correct. > > > >> Do you know if the target entry has 'ipatokenOwner' or > >> 'managedBy' with the binddn value ? > > Yes, both. So why is access to objectClass (et cetera) being denied? > Good question... I will try to reproduce
Thanks! > >>> 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. > >> It may not querying all attributes, but just search the first > >> one it can read. > >> As it finds none of them you get the message for all > >> attributes. > > Right, but why iterate through all possible attributes? It should only > > iterate through the attributes requested. Whether the user can read a > > non-requested attribute or not is irrelevant because the attribute was > > not requested. > I think it is iterating from the attributes in the entry. Searching the > first one that the authenticated subject is allowed to read. I agree. The question is: why? Nathaniel _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel