On Sat, Jun 20, 2015 at 9:36 AM, Thomas Mortagne
<thomas.mortagne(a)xwiki.com>
 wrote:
  On Fri, Jun 19, 2015 at 5:42 PM, Eduard Moraru
<enygma2002(a)gmail.com>
 wrote:
  Hi,
 On Fri, Jun 19, 2015 at 5:42 PM, Thomas Mortagne < 
thomas.mortagne(a)xwiki.com>
  wrote:
> On Fri, Jun 19, 2015 at 4:25 PM, Eduard Moraru <enygma2002(a)gmail.com>
> wrote:
> > Hi,
> >
> > For 7.2, we are introducing a new right to control permissions on the
> > execution of scripts.
> >
> > Right now, out of all the scripts we support, Velocity is special and
> does
> > not require programming rights, since it uses only the public API. Of
> > course, if it has PR available, it can also access privileged API. All
> > other scripts (groovy, python, etc) require PR by default.
> >
> > The new 'script' right should be used to control
"light"/sandboxed
> > scripting, such as velocity or any other scripts that are configured 
 to
   >
consider this new right when executing (assuming they override the
 standard
 > PR check).
 We actually do have another one already, a custom version of Groovy
 JSR223 engine done by Vincent.
 All that to say that you should probably also update
 org.xwiki.rendering.internal.macro.groovy.GroovyMacroPermissionPolicy
 in xwiki-platform-rendering-macro-groovy module.
 
 I have noticed it, but did not touch it since I see it has a custom way 
  of
  restricting execution (it sets a 'secure'
flag in the groovy 
 configuration
  that tells it to consider if the macro
transformation context is 
 restricted
  or not and, if not restricted, it does not need
PR, but delegates to a
 Groovy dedicated security customizer) and if that is not used/configured,
 it falls back to programming rights.
 Do you think we need to or should do more than that for Groovy? If not
 custom security customizer is set, then PR decide if a groovy script runs
 or not (which is often the case). And if so, what do you propose? 
 I know how it's working and the goal of this customisation is allow
 using Groovy without PR in which case it should require Script right
 exactly like Velocity does. It would not make much sense to not be
 allowed to do Velocity when you can do Groovy.
 
 I see. At first I did not understand what you mean, but now I do.
 Basically, you want "light"/limited groovy scripts (running with a secure
 customizer) to be handled consistently, just like just velocity scripts,
 which makes sense.
 In other words, this: