On 02/25/2014 05:36 PM, Rich Megginson wrote:
> On 02/25/2014 09:28 AM, thierry bordaz wrote:
>> On 02/25/2014 04:53 PM, Ludwig Krispenz wrote:
>>>
>>> On 02/25/2014 04:45 PM, Rich Megginson wrote:
>>>> On 02/25/2014 08:28 AM, thierry bordaz wrote:
>>>>> On 02/25/2014 04:17 PM, Rich Megginson wrote:
>>>>>> On 02/25/2014 08:14 AM, thierry bordaz wrote:
>>>>>>> On 02/25/2014 03:46 PM, Rich Megginson wrote:
>>>>>>>> On 02/25/2014 07:42 AM, thierry bordaz wrote:
>>>>>>>>> On 02/25/2014 03:34 PM, Rich Megginson wrote:
>>>>>>>>>> On 02/25/2014 07:24 AM, thierry bordaz wrote:
>>>>>>>>>>> On 02/24/2014 10:47 PM, Noriko Hosoi wrote:
>>>>>>>>>>>> Rich Megginson wrote:
>>>>>>>>>>>>> On 02/24/2014 09:00 AM, thierry
bordaz wrote:
>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> IPA team filled this ticket
>>>>>>>>>>>>>>
https://fedorahosted.org/389/ticket/47553.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> It requires an ACI
improvement so that during a
>>>>>>>>>>>>>> MODDN a given user is only
allowed to move an entry
>>>>>>>>>>>>>> from one specified part of
the DIT to an other
>>>>>>>>>>>>>> specified part of the DIT.
This without the need to
>>>>>>>>>>>>>> grant the ADD permission.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here is the design of what
could be implemented to
>>>>>>>>>>>>>> support this need
>>>>>>>>>>>>>>
http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operation
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> regards
>>>>>>>>>>>>>> thierry
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since this not related to any Red Hat
internal or
>>>>>>>>>>>>> customer information, we should move
this discussion to
>>>>>>>>>>>>> the 389-devel list.
>>>>>>>>>>>>>
>>>>>>>>>>>> Hi Thierry,
>>>>>>>>>>>>
>>>>>>>>>>>> Your design looks good. A minor
question. The doc does
>>>>>>>>>>>> not mention about "deny". For
instance, in your example
>>>>>>>>>>>> DIT, can I allow "moddn_to" and
"moddn_from" on the top
>>>>>>>>>>>> "dc=example,dc=com" and deny
them on "cn=tests". Then, I
>>>>>>>>>>>> can move an entry between cn=accounts and
staging, but not
>>>>>>>>>>>> to/from cn=tests? Or "deny" is
not supposed to use there?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> --noriko
>>>>>>>>>>>
>>>>>>>>>>> Hi Noriko,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for having looked at the document. You
are right, I
>>>>>>>>>>> missed to document how 'DENY' aci
would work.
>>>>>>>>>>>
>>>>>>>>>>> I updated the design
>>>>>>>>>>>
http://port389.org/wiki/Access_control_on_trees_specified_in_MODDN_operat...
>>>>>>>>>>> to indicate how a DENY rights could be used.
>>>>>>>>>>>
>>>>>>>>>>> By default if there is no ACI granting
'allow', the
>>>>>>>>>>> operation is rejected. So in that case,
without ACI
>>>>>>>>>>> applicable on 'cn=tests', MODDN
to/from 'cn=tests' will not
>>>>>>>>>>> be authorized.
>>>>>>>>>>> Adding a DENY to target 'cn=tests'
would also work but I
>>>>>>>>>>> think it is not required.
>>>>>>>>>>>
>>>>>>>>>>> In the example I added, the 'ALLOW'
right is granted to a
>>>>>>>>>>> tree (cn=accounts,SUFFIX) except to a subtree
of it
>>>>>>>>>>> (cn=except,cn=accounts,SUFFIX)
>>>>>>>>>>
>>>>>>>>>> So in order to do a MODDN operation, you need
both the
>>>>>>>>>> moddn_from aci and moddn_to aci?
>>>>>>>>>>
>>>>>>>>>> For example:
>>>>>>>>>>
>>>>>>>>>> dn: dc=example,dc=com
>>>>>>>>>> aci:
(target="ldap:///cn=staging,dc=example,dc=com")(version
>>>>>>>>>> 3.0; acl "MODDN from"; allow
(moddn_from))
>>>>>>>>>>
userdn="ldap:///uid=admin_accounts,dc=example,dc=com" ;)
>>>>>>>>>>
>>>>>>>>>> If I only have this aci, will it allow anything?
That is,
>>>>>>>>>> if I don't have a (moddn_to) aci somewhere,
will this
>>>>>>>>>> (moddn_from) aci allow me to move anything?
>>>>>>>>>
>>>>>>>>> Yes it will allow you to do a MODDN if you are
granted the
>>>>>>>>> 'ADD' right on the new superior entry.
>>>>>>>>>
>>>>>>>>> I think this double ACI can be an issue as freeipa
was hoping
>>>>>>>>> to use a single ACI. But I have not found a solution
to grant
>>>>>>>>> move (to/from) in a single aci syntax.
>>>>>>>>
>>>>>>>> I think it is very important to specify both the source
and
>>>>>>>> the destination of a MODDN operation. I don't think
this will
>>>>>>>> be possible in all cases without having 2 target DNs in a
>>>>>>>> single ACI statement.
>>>>>>>
>>>>>>> My concern is that if we have something like :
>>>>>>>
>>>>>>> aci: target_rule (version 3.0; acl "MODDN control";
allow
>>>>>>> (moddn_to, moddn_from)
>>>>>>> bind_rule;)
>>>>>>>
>>>>>>> and 'target_rule' defines two DNs, then moddn_to/from
are
>>>>>>> granted for both DNs. so in our case, the user would be
allowed
>>>>>>> to move an entry staging->accounts but also
account->staging.
>>>>>>
>>>>>> Right. It is necessary to be able to specify
moddn_from="DN1"
>>>>>> modrn_to="DN2"
>>>>>
>>>>> Ok yes it would work.
>>>>>
>>>>> Now I am unsure of the benefit of having a single aci with that
>>>>> new 'target_rule' syntax compare to two aci with the current
>>>>> syntax. I can imagine a performance gain in terms of aci scan and
>>>>> evaluation but wonder if there is an other benefit.
>>>>
>>>> One problem with having two acis is referential integrity -
>>>> keeping the pairs in sync with other changes. Having to keep
>>>> track of two acis is much more than twice as difficult as keeping
>>>> track of a single aci.
>>>>
>>>> I can appreciate that it will be very difficult to change the aci
>>>> syntax in such a way as to support two target clauses in a single
>>>> aci. And, it might not be sufficient to simply have
>>>>
>>>> aci:
(target_from="ldap:///dn_from")(target_to="ldap:///dn_to")...
>>> That would be a possibility, we could have multiple acis of the form
>>> aci:
>>>
(target_from="ldap:///dn_from")(target_to="ldap:///dn_to")..allow(moddn);.......
>>>
>>> to define all allowed moves.
>>> So two new targets and one new permission: moddn
>>
>> yes very nice !
>> That means that to be selected during the scan phase, the aci should
>> be at upper level that dn_from and dn_to.
>
> Not sure what you mean. Do you mean the entry in which you set the
> aci attribute must be a parent/ancestor of both the target_to DN and
> the target_from DN?
>
yes
I would prefer not to have that restriction unless:
1) we already have this restriction for (target="ldap:///DN") clauses
2) it is very difficult to implement
>> Also what to do if 'target_to'/'target_from'
are missing, to replace
>> them with the entry DN having the aci ?
>
> I think it would be better to have to specify both target_to and
> target_from - that way there is no ambiguity.
>
> You still have to handle the problem of referential integrity e.g.
> what if someone renames target_from or target_to?
Right. I missed that !
>
>>
>>>>
>>>> although I'm not sure if any of the other target keywords are
>>>> applicable here - like targetattr, targetfilter, targattrfilter, etc.
>>>>
>>>>>
>>>>> I sent the design pointer to freeipa-devel as well, sure I will
>>>>> get some comments on that :-)
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> regards
>>>>>>>>>>> thierry
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> 389-devel mailing list
>>>>>>>>>>>> 389-devel(a)lists.fedoraproject.org
>>>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> 389-devel mailing list
>>>>>>>>>>> 389-devel(a)lists.fedoraproject.org
>>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 389-devel mailing list
>>>>>>>>>> 389-devel(a)lists.fedoraproject.org
>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 389-devel mailing list
>>>> 389-devel(a)lists.fedoraproject.org
>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
>>>
>>>
>>>
>>> --
>>> 389-devel mailing list
>>> 389-devel(a)lists.fedoraproject.org
>>>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
>>
>>
>>
>> --
>> 389-devel mailing list
>> 389-devel(a)lists.fedoraproject.org
>>
https://admin.fedoraproject.org/mailman/listinfo/389-devel
>
>
>
> --
> 389-devel mailing list
> 389-devel(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-devel