MetaClass delegate handling

[jglick]

Found that a trick used to bind synthetic methods to existing classes was being rejected by the sandbox. Here it is assumed that the closure itself is implicitly whitelisted; Whitelist does not have any mechanism for listing non-Java “methods” like this.

@reviewbybees esp. @kohsuke

[jglick]

Not really related but came up as a desired whitelist entry in the same context.

[ghost]

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

[kohsuke]

IIUC, this allows any closure invocation, such as those obtained via method pointer operation. Is this safe? Looking at the test case, it seems like this case should be checked against String.getAnswer() method.

🐝 so as not to block Jesse in case I got it all wrong.

[jenkinsadmin]

Thank you for this pull request! Please check this document for how the Jenkins project handles pull requests.

[jglick]

I could check whether it applies also to method pointers. I am not too concerned even if it does, since DefaultGroovyMethod.getMetaClass and MetaClass.setProperty will still be rejected, so you could not use that to mount an attack—a trusted source would have to have installed the metamethod to begin with. Or are you saying something else @kohsuke?

[kohsuke]

I think I confused myself with earlier question about allowing any closure invocation, so I take that back.

[andresrc]

🐝

[kohsuke]

I consider my previous 🐝 standing, but here's another one because process!!

🐝