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