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