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