|
On 02/25/2014 10:00 AM, thierry bordaz
wrote:
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 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.
Ok.
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@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
--
389-devel mailing list
389-devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-devel
|
