Thanks to all your feedbacks, they helped me a lot and raised a
severe limitation in the original design.
I updated the design following the aci syntax proposed during the
On the implementation side, it is a bit more complex but less than I
expected. I have not yet investigated the impact of ger operations.
I think a big work will be the test side as the ACI syntax provides
Note: I kept for the moment the original design in 'alternative no1'.
Rich Megginson wrote:
> On 02/24/2014 09:00 AM, thierry bordaz wrote:
>> IPA team filled this ticket
>> 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
> Since this not related to any Red Hat internal or customer
> information, we should move this discussion to the 389-devel list.
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?
I noticed that some shell scripts have bashisms in them, on Debian and
it's derivatives /bin/sh is dash. A quick list of scripts shipped by
389-ds-base having this issue:
but since I just ran all the scripts without any options, there might be
others too that fail with "unexpected operator" errors etc when ran in a
real environment. So maybe change all of them to use /bin/bash or
migrate them to be posix compatible (and somehow test new ones for
Thanks Mark and Rich for your reviews !!
Rereading the comments I found a different fix, that instead of fixing
'plugin_setup' (that is common to plugin init and
slapi_register_plugin), I made the fix only on slapi_register_plugin
where the precedence was forced to a default value. Please let me know
if you prefer the previous fix or the second.