<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: </div> <blockquote cite="mid:1412872807.3262.10.camel@redhat.com" type="cite"> <pre wrap="">On Thu, 2014-10-09 at 18:32 +0200, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 10/09/2014 06:27 PM, Nathaniel McCallum wrote: </pre> <blockquote type="cite"> <pre wrap="">On Thu, 2014-10-09 at 14:11 +0200, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 10/08/2014 11:46 PM, Nathaniel McCallum wrote: </pre> <blockquote type="cite"> <pre wrap="">The background of this email is this bug: <a class="moz-txt-link-freetext" href="https://fedorahosted.org/freeipa/ticket/4456">https://fedorahosted.org/freeipa/ticket/4456</a> Attached are two patches which solve this issue for admin users (not very helpful, I know). They depend on this fix in 389: <a class="moz-txt-link-freetext" href="https://fedorahosted.org/389/ticket/47920">https://fedorahosted.org/389/ticket/47920</a> 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 </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Agreed and understood. </pre> <blockquote type="cite"> <pre wrap=""> 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". </pre> </blockquote> <pre wrap="">Correct. </pre> <blockquote type="cite"> <pre wrap=""> 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";) </pre> </blockquote> <pre wrap="">Correct. </pre> <blockquote type="cite"> <pre wrap=""> Do you know if the target entry has 'ipatokenOwner' or 'managedBy' with the binddn value ? </pre> </blockquote> <pre wrap="">Yes, both. So why is access to objectClass (et cetera) being denied? </pre> </blockquote> <pre wrap="">Good question... I will try to reproduce </pre> </blockquote> <pre wrap=""> Thanks!</pre> </blockquote> Hello, <blockquote>I tried to reproduce and it seems to work on *master*. I am using the attached ldif file. The test case is to bind as "cn=active guy,cn=accounts,dc=example,dc=com" and to do a modify on "cn=active otp,cn=otp,dc=example,dc=com". The modify updates the 'description' attribute and do a postread (description, cn). The write 'description' is allowed by : <blockquote><tt>dn: cn=otp,dc=example,dc=com</tt> <tt>aci: (targetfilter = "(objectclass=organizationalPerson)")(target = "<a class="moz-txt-link-freetext" href="ldap:///c">ldap:///c</a></tt> <tt> n=*,cn=otp,dc=example,dc=com")(targetattr = "objectclass || description || se</tt> <tt> eAlso")(version 3.0; acl "Active user modify otp entry"; allow (write) userdn</tt> <tt> = <a class="moz-txt-link-rfc2396E" href="ldap:///cn=activeguy,cn=accounts,dc=example,dc=com">"ldap:///cn=active guy,cn=accounts,dc=example,dc=com"</a>;)</tt> <tt>[09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) " "Active user modify otp entry""</tt> <tt>[09/Oct/2014:22:07:56 +0200] NSACLPlugin - conn=2 op=16 (main): Allow write on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(description) to cn=active guy,cn=accounts,dc=example,dc=com: allowed by aci(19): aciname= "Active user modify otp entry", acidn="cn=otp,dc=example,dc=com"</tt> </blockquote> The postread is allowed by: <blockquote><tt>dn: cn=otp,dc=example,dc=com</tt> <tt>aci: (targetfilter = "(objectclass=organizationalPerson)") (targetattr = "obje</tt> <tt> ctclass || description || seeAlso || cn")(version 3.0; acl "Active user can r</tt> <tt> ead his entries"; allow (read, search, compare) userattr = "seeAlso#USERDN";)</tt> <tt>[09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) " "Active user can read his entries""</tt> <tt>[09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache</tt> <tt>[09/Oct/2014:22:07:58 +0200] NSACLPlugin - conn=2 op=16 (main): Allow read on entry(cn=active otp,cn=otp,dc=example,dc=com).attr(cn) to cn=active guy,cn=accounts,dc=example,dc=com: cached allow by aci(21)</tt> </blockquote> The postread works if I use USERDN or SELFDN. Please let me know the version of 389-ds that you are testing, I will try on that branch thanks thierry </blockquote> <blockquote cite="mid:1412872807.3262.10.camel@redhat.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">The ACIs allowing access to most of these attributes are here: <a class="moz-txt-link-freetext" href="https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90">https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/default-aci.ldif#n90</a> 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. </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">I think it is iterating from the attributes in the entry. Searching the first one that the authenticated subject is allowed to read. </pre> </blockquote> <pre wrap=""> I agree. The question is: why? Nathaniel </pre> </blockquote> </body> </html>