Generate closures as public classes

[ywelsch]

Groovy is the default scripting language in Elasticsearch, used to evaluate custom expressions. In Elasticsearch 2.0 we introduced the Java security manager as a key component to secure our software. We spent a lot of effort on getting Groovy to run under the security manager with a conservative set of permissions. We have currently hit a road block with the suppressAccessCheck which allows suppressing the standard language access checks and expose information that would normally be unavailable to malicious code. Unfortunately, not providing this permission to Groovy breaks the use of Groovy closures in our scripts.

The reason is that in the Groovy framework:

• Closures are generated as package private classes.
• Access to closures is cached by the Groovy runtime using the class CachedMethod.

Invoking a closure thus fails without the suppressAccessCheck permission as the class of the closure is package private but accessed from the Groovy runtime class CachedMethod in the org.codehaus.groovy.reflection package.

This one-line PR changes the access modifier of the classes generated for Groovy closures from package-private to public.

[blackdrag]

How does the situation with CachedMethod change if the generated closure is public?

[pickypg]

I went ahead and created a JIRA issue for it: GROOVY-7735.

How does the situation with CachedMethod change if the generated closure is public?

@blackdrag As the change increases the access level of the generated Closure class, it has no negative impact on the CachedMethod class. Given that that class' job is to invoke cached methods, it seems better to have the appropriate permission level for the Closure with respect to it "doing the right thing".

[rmuir]

How does the situation with CachedMethod change if the generated closure is public?

It also means code running under securitymanager can invoke it without granting ReflectPermission("suppressAccessChecks") which is dangerous.

Basically, groovy should respect java's access modifiers here.

[blackdrag]

The choice was not really arbitrary. Anonymous inner classes will also not be public in Java. But well... I think there will be no real ill side effects we have to fear here. So +1 from my side... Only a minor improvement could be done and that is either to comment in code or at least in the commit message as of why we use public. Otherwise it might be changed again in the future... And of course something like a test would be nice too, but the comment is more important to me

[ywelsch]

@blackdrag I've added a comment to the code and an explanation for the code change in the commit message. Please let me know if anything else is needed to get this in.

[pickypg]

To add to it being public, I looked for other usage of getOrAddClosureClass and I only found two other instances, both of which also pass ACC_PUBLIC:

• org.codehaus.groovy.classgen.AsmClassGenerator#453
• org.codehaus.groovy.classgen.AsmClassGenerator#1902

Perhaps a future PR should deprecate the method and remove the second argument, but I'm happy to see the +1 here. (PS: Jenkins failed to actually start Gradle, which is why the build failed)

[blackdrag]

those other two findings are for Closures in annotations. They actually do need to be public. Anyway... +1 for the change

[paulk-asert]

+1 from my side

[PascalSchumacher]

Merged: 7ced8a2 Thanks!

[PascalSchumacher]

@ywelsch Could you please close the pull request? I can not because this is a read only-repo (and I forgot to add the right comment to the commit message :().

Thanks!

[ywelsch]

@PascalSchumacher thanks for merging this!