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