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:

Attached are two patches which solve this issue for admin users
(not very helpful, I know). They depend on this fix in 389:

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:

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
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


Freeipa-devel mailing list

Reply via email to