Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
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? But this is a general problem already: if you have an aci in dc=example,dc=com with a normal target ou=people,dc=example,dc=com and you rename ou=people the aci is not changed. The same is true in bindrules if you have an allow for userdn=ldap:///cn=x,ou=y,o=suffix and move cn=x to ou=z the bind rule no longer applies. -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
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. regards thierry -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
On 02/25/2014 04:14 PM, 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. I think it will b every difficult to handle this with current aci syntax elements. The question is how detailled do we want to control the moviong of entries ? The current design satisfies the needs of freeipa, at least I think so, but if we have more complex scenarios like a dit wit four subtrees A,B,C,D and we want to allow modrdn A-C, A-D, D-B, C-A then I think it impossible to achieve this with moddn_to|from only. regards thierry -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
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;)... 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
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_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 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
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
On 02/25/2014 05:34 PM, Mark Reynolds wrote: 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_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 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? no. targets usually target subtrees, so if _to and _from
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
On 02/25/2014 05:34 PM, Mark Reynolds wrote: 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_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 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
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
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_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 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
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Design review: Access control on entries specified in MODDN operation (ticket 47553)
On 02/24/2014 02: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? In which entry do you set these ACIs? Do you set 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; ;) in the cn=accounts,dc=example,dc=com entry? Do you set aci: (target=ldap:///cn=accounts,dc=example,dc=com;)(version 3.0; acl MODDN to; allow (moddn_to)) userdn=ldap:///uid=admin_accounts,dc=example,dc=com; ;) in the cn=staging,dc=example,dc=com entry? Thanks, --noriko -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
