On 10/09/2014 06:32 PM, 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...
+1
could you post the full aci logging not only the summary for the access
to the attributes ?
I will try to reproduce
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.
thanks
thierry
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
