On 10/09/2014 05:51 PM, Nathaniel McCallum wrote:
On Thu, 2014-10-09 at 16:33 +0200, Ludwig Krispenz 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 ?
This is the ldif I used:
dn: ipatokenuniqueid=autogenerate,cn=otp,dc=example,dc=com
changetype: add
objectClass: top
objectClass: ipaToken
objectClass: ipaTokenHOTP
ipatokenUniqueID: autogenerate
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
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
No. Issue #2 is unrelated to issue #1. In issue #2, the add itself
fails.
is this because of the change from tokenuiqieid=* to
tokenuniqueid=autogenerate in the aci, why not stick to*
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
