<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/10/2014 04:38 PM, Ludwig Krispenz wrote: </div> <blockquote cite="mid:5437EF66.7090201@redhat.com" type="cite"> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <div class="moz-cite-prefix">On 10/10/2014 03:58 PM, thierry bordaz wrote: </div> <blockquote cite="mid:5437E621.2000302@redhat.com" type="cite"> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <div class="moz-cite-prefix">On 10/09/2014 10:51 PM, Nathaniel McCallum wrote: </div> <blockquote cite="mid:1412887903.3262.14.camel@redhat.com" type="cite"> <pre wrap="">On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: </pre> <blockquote 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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> <pre wrap="">Hello, 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 : dn: cn=otp,dc=example,dc=com aci: (targetfilter = "(objectclass=organizationalPerson)")(target = <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="ldap:///cn=*,cn=otp,dc=example,dc=com">"ldap:///c n=*,cn=otp,dc=example,dc=com"</a>)(targetattr = "objectclass || description || se eAlso")(version 3.0; acl "Active user modify otp entry"; allow (write) userdn = <a moz-do-not-send="true" 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>;) [09/Oct/2014:22:07:56 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(19) " "Active user modify otp entry"" [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" The postread is allowed by: dn: cn=otp,dc=example,dc=com aci: (targetfilter = "(objectclass=organizationalPerson)") (targetattr = "obje ctclass || description || seeAlso || cn")(version 3.0; acl "Active user can r ead his entries"; allow (read, search, compare) userattr = "seeAlso#USERDN";) [09/Oct/2014:22:07:58 +0200] NSACLPlugin - 1. Evaluating ALLOW aci(21) " "Active user can read his entries"" [09/Oct/2014:22:07:58 +0200] NSACLPlugin - Found READ ALLOW in cache [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) 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 </pre> </blockquote> <pre wrap="">That is not really the same test at all. 1. Install FreeIPA from F21 @ example.com 2. Excecute: ldapadd -D uid=admin,cn=users,cn=accounts,dc=example,dc=com -W -e postread=* <<EOF dn: ipatokenuniqueid=foo,cn=otp,dc=example,dc=com changetype: add objectClass: top objectClass: ipaToken objectClass: ipaTokenHOTP ipatokenUniqueID: foo ipatokenOTPalgorithm: sha1 ipatokenOTPdigits: 6 ipatokenOTPkey: 00000000 ipatokenHOTPcounter: 0 ipatokenOwner: uid=admin,cn=users,cn=accounts,dc=example,dc=com managedBy: uid=admin,cn=users,cn=accounts,dc=example,dc=com EOF 3. Create a regular user named 'otp' 4. Execute: ldapadd -D uid=otp,cn=users,cn=accounts,dc=example,dc=com -W -e postread=* <<EOF dn: ipatokenuniqueid=bar,cn=otp,dc=example,dc=com changetype: add objectClass: top objectClass: ipaToken objectClass: ipaTokenHOTP ipatokenUniqueID: bar 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 EOF RESULTS: Step 2 will add the token and return the post read control. Step 4 will add the token, but will NOT return the post read control. </pre> </blockquote> Hi Nathaniel, <blockquote>Thanks for the detailed procedure I was able to reproduce the problem: In fact during the step for, the add is successful but the found ACIs do no grant access to the target entry: <blockquote><tt>[09/Oct/2014:21:34:58 -0400] conn=29 fd=82 slot=82 SSL connection from 10.16.78.124 to 10.16.78.124</tt> <tt>[09/Oct/2014:21:34:58 -0400] conn=29 SSL 128-bit AES</tt> <tt>[09/Oct/2014:21:34:58 -0400] conn=29 op=0 BIND dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com" method=128 version=3</tt> <tt>[09/Oct/2014:21:34:58 -0400] conn=29 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=otp,cn=users,cn=accounts,dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:58 -0400] conn=29 op=1 ADD dn="ipatokenuniqueid=bar,cn=otp,dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:59 -0400] conn=29 op=2 UNBIND</tt> <tt>[09/Oct/2014:21:34:59 -0400] conn=29 op=2 fd=82 closed - U1</tt> <tt>[09/Oct/2014:21:34:59 -0400] conn=29 op=1 RESULT err=0 tag=105 nentries=0 etime=1</tt> </blockquote> The add was granted because of "Users can create self-managed tokens" <blockquote> <tt>[09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 (main): Allow add on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(NULL) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: allowed by aci(16): aciname= "Users can create self-managed tokens", acidn="dc=example,dc=com"</tt> </blockquote> Now the postread control was not granted for any of the attribute of the entry: <blockquote><tt>[09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(objectClass) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:58 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenUniqueID) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenOTPalgorithm) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenOTPdigits) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenOTPkey) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenHOTPcounter) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(ipatokenOwner) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> </blockquote> Each time the correct aci was selectionned: <blockquote> <tt>aci: (targetfilter = "(objectClass=ipaToken)")(targetattrs = "objectclass || d</tt> <tt> escription || managedBy || ipatokenUniqueID || ipatokenDisabled || ipatokenNo</tt> <tt> tBefore || ipatokenNotAfter || ipatokenVendor || ipatokenModel || ipatokenSer</tt> <tt> ial || ipatokenOwner")(version 3.0; acl "Users/managers can read basic token</tt> <tt> info"; allow (read, search, compare) userattr = "ipatokenOwner#USERDN" or use</tt> <tt> rattr = "managedBy#USERDN";)</tt> <tt>... [09/Oct/2014:21:34:59 -0400] NSACLPlugin - Processed attr:managedBy for entry:ipatokenuniqueid=bar,cn=otp,dc=example,dc=com</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - 1. Evaluating ALLOW aci(11) " "Users/managers can read basic token info""</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in cache</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - 2. Evaluating ALLOW aci(19) " "Admin can manage any entry""</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - Found READ SKIP in cache</tt> <tt>[09/Oct/2014:21:34:59 -0400] NSACLPlugin - conn=29 op=1 (main): Deny read on entry(ipatokenuniqueid=bar,cn=otp,dc=example,dc=com).attr(managedBy) to uid=otp,cn=users,cn=accounts,dc=example,dc=com: no aci matched the subject by aci(19): aciname= "Admin can manage any entry", acidn="dc=example,dc=com"</tt> <tt>[09/Oct/2014:21:34:59 -0400] - process_read_entry_controls: access to entry not allowed (ipatokenuniqueid=bar,cn=otp,dc=example,dc=com)</tt> </blockquote> But for some reason, it evaluations of the READ access was not accepted. </blockquote> </blockquote> the key is READ SKIP, looks like it is using cached evaluation of the acis, where the aci did not apply. aci caching is .... </blockquote> Exact. Now If I create two entries x/y and their associated ipatoken tokenX/tokenY and play updating x update tokenX then y updates tokenY x update tokenX then x updates tokenY y update tokenY then x updates tokenX ... each time I got the postread. Something curious going on that make ACL_EvalTestRights return something different that ACL_RES_ALLOW. <blockquote cite="mid:5437EF66.7090201@redhat.com" type="cite"> <blockquote cite="mid:5437E621.2000302@redhat.com" type="cite"> <blockquote> Did you already open a ticket for this problem ? thanks thierry </blockquote> </blockquote> </blockquote> </body> </html>