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