On 02/25/2014 04:45 PM, Rich Megginson wrote:
> 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
That would be preferable for me as well. I think we want to be able to control
the from-to pair in one ACI. Because if we have containers like the following:
- cn=system users,SUFFIX
- cn=staged system users,SUFFIX
- cn=staged users,SUFFIX
- cn=users,SUFFIX
And if I have an unprivileged user with the original ACIs, i.e.
- moddn_from staged system users
- moddn_to system users
- moddn_from staged users
- moddn_to users
the user would be able to move staged system users to users or staged users to
system users - which IMO is not OK.
Martin