On 10/09/2014 04:47 PM, Simo Sorce wrote:
On Thu, 09 Oct 2014 16:33:20 +0200
Ludwig Krispenz <lkris...@redhat.com> wrote:
On 10/09/2014 04:27 PM, Simo Sorce wrote:
On Thu, 09 Oct 2014 16:06:06 +0200
Ludwig Krispenz <lkris...@redhat.com> wrote:
On 10/09/2014 03:13 PM, Simo Sorce wrote:
On Wed, 08 Oct 2014 17:46:01 -0400
Nathaniel McCallum <npmccal...@redhat.com> 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
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.
Can you show an example ldif ?
I wonder if you are setting the owner ?
2. The second patch (0002) modifies the ACI for normal user token
addition from this:
aci: (target =
"ldap:///ipatokenuniqueid=*,cn=otp,$SUFFIX";)(targetfilter =
"(objectClass=ipaToken)")(version 3.0; acl "Users can create
self-managed tokens"; allow (add) userattr =
"ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
To this:
aci: (target = "ldap:///ipatokenuniqueid=autogenerate,cn=otp,
$SUFFIX")(targetfilter = "(objectClass=ipaToken)")(version 3.0;
acl "Users can create self-managed tokens"; allow (add) userattr
= "ipatokenOwner#SELFDN" and userattr = "managedBy#SELFDN";)
The idea is to allow users to create tokens which will be
expanded by the UUID plugin. Unfortunately, after the UUID is
expanded, the ACIs are checked. Since the expanded UUID no
longer matches the ACI, the addition is denied. Is this truly
the correct behavior? I would think that the ACIs would be
checked before the UUID plugin, not after.
I would expect the same, can someone on the DS team comment ?
acis are always applied before the entry is sent to the client. the
control is added when the result is sent and for the postop control
it gets the POST_OP entry and checks read access to teh entry
So you think the whole add was denied because the post-read couldn't
read back the entry ?
as far as I understood Nathaniel, the add succeeded, only the control
was not returned
Then fixing the read-related issue is all we need ?
you need an aci allowing to read the postop entry
Btw we could add userattr = creatorsName#SELFDN" to the read ACI so that
ipatokenOwner/managedby are not strictly needed for post-read ?
Does it make sense to do ?
I'm not sure, are there cases when tokenOwner is not set or different
from selfdn ? Could anyone else create the token for another user (an
admin )?
I don't see what the entry really looked like when trying to create the
control, and who was "self" in that scenario. In Nathaniel's post access
was denied to uid=otp,.... is this the tokenwoner ?
Simo.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
