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.
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
https://admin.fedoraproject.org/mailman/listinfo/389-devel