On 02/25/2014 05:56 PM, Rich Megginson wrote:
> 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
>>
>