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.
I think it will b every
difficult to handle this with current aci syntax
elements. The question is how detailled do we want to control the
moviong of entries ?
The current design satisfies the needs of freeipa, at least I think so,
but if we have more complex scenarios like a dit wit four subtrees
A,B,C,D and we want to allow modrdn
A->C, A->D, D->B, C->A then I think it impossible to achieve this with
moddn_to|from only.
>
>>>
>>>>
>>>> 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