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 -- 389-devel mailing list 389-devel(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel

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

-- 389-devel mailing list 389-devel(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel

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?

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

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.

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

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"

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

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")...

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

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

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

On 02/25/2014 11: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. > 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 -- 389-devel mailing list 389-devel(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel

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 ?

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

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

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

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

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?