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