On 02/25/2014 09:51 AM, thierry bordaz wrote:
> On 02/25/2014 05:36 PM, Rich Megginson wrote:
>> On 02/25/2014 09:28 AM, thierry bordaz wrote:
>>> On 02/25/2014 04:53 PM, Ludwig Krispenz wrote:
>>>>
>>>> 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
>>>
>>> yes very nice !
>>> That means that to be selected during the scan phase, the aci
>>> should be at upper level that dn_from and dn_to.
>>
>> Not sure what you mean. Do you mean the entry in which you set the
>> aci attribute must be a parent/ancestor of both the target_to DN and
>> the target_from DN?
>>
> yes
I would prefer not to have that restriction unless:
1) we already have this restriction for (target="ldap:///DN") clauses
2) it is very difficult to implement
I am not sure if it is a restriction enforced when creating an aci, but
as far as I remember when scanning the applicable ACIs, it uses aci
stores in parents entries then evaluate the target rules.
>>> Also what to do if
'target_to'/'target_from' are missing, to
>>> replace them with the entry DN having the aci ?
>>
>> I think it would be better to have to specify both target_to and
>> target_from - that way there is no ambiguity.
>>
>> You still have to handle the problem of referential integrity e.g.
>> what if someone renames target_from or target_to?
>
> Right. I missed that !
>
>>
>>>
>>>>>
>>>>> 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
>>>>
>>>>
>>>>
>>>> --
>>>> 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
>