On Thu, 2014-10-09 at 22:22 +0200, thierry bordaz wrote: > On 10/09/2014 06:40 PM, Nathaniel McCallum wrote: > > > 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! > > 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 = > "ldap:///c > n=*,cn=otp,dc=example,dc=com")(targetattr = > "objectclass || description || se > eAlso")(version 3.0; acl "Active user modify otp > entry"; allow (write) userdn > = "ldap:///cn=active > guy,cn=accounts,dc=example,dc=com";) > > [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
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. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel