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_operation#ACI_allow.2Fdeny_rights >>>>>>>>> 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 -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
