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? > > 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. _______________________________________________ Freeipa-devel mailing list Freeipafirstname.lastname@example.org https://www.redhat.com/mailman/listinfo/freeipa-devel