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
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@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
--
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
--
Mark Reynolds
389 Development Team
Red Hat, Inc
mreynolds@xxxxxxxxxx
|
