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.
Also what to do if 'target_to'/'target_from' are missing, to replace
them with the entry DN having the aci ?
Wouldn't that be meaningless? So if
the entry dn is ou=A - you'd allow
someone to move an entry from ou=A to ou=A? :-) Couldn't we make it a
aci syntax violation?
>>
>> 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
--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreynolds(a)redhat.com