Odd script config behavior

[mal]

Just upgraded from 1.2.1 with the groovy plugin to 1.3.1 (plugin removed) and I'm seeing some weird behaviour when trying to use my installed scripts, I've written a test script here.

Settings

script.disable_dynamic: true

Query

{
  "script_fields": {
    "minimum": {
      "lang": "groovy",
      "script": "lowest",
      "params": {
        "field": "vals"
      }
    }
  }
}

Script

GroovyCollections.min(doc[field].values as Integer[])

Results

ScriptException[dynamic scripting for [groovy] disabled]

Which, while true, shouldn't apply since I'm trying to run a script stored on disk ...

[dakrone]

Hi @mal,

I'm trying to reproduce this issue with your example, I actually get a different exception due to GroovyCollections not being allowed by the groovy sandbox. Is it possible that you are running mixed versions of Elasticsearch in your environment?

Can you give me the full stacktrace of the exception?

Also, when you put the script in config/scripts, do you see the log message about the script being compiled by Elasticsearch?

[mal]

Aha, it fails to compile so I guess it doesn't get found and ES assumes lowest is a dynamic script.

[2014-07-30 11:36:37,180][WARN ][script                   ] [Honcho] failed to load/compile script [lowest]
org.elasticsearch.script.groovy.GroovyScriptCompilationException: MultipleCompilationErrorsException[startup failed:
General error during canonicalization: Method calls not allowed on [groovy.util.GroovyCollections]

I tried adding groovy.util.GroovyCollections to the receiver_whitelist, but that didn't work either:

[2014-07-30 11:39:53,907][WARN ][script                   ] [Heart Attack] failed to load/compile script [lowest]
org.elasticsearch.script.groovy.GroovyScriptCompilationException: MultipleCompilationErrorsException[startup failed:
General error during canonicalization: Property access not allowed on [java.lang.Object]

[dakrone]

I tried adding groovy.util.GroovyCollections to the receiver_whitelist, but that didn't work either:

How did you add it to the receiver_whitelist? I can try to reproduce it.

Also, going forward, looking at the javadoc I don't see any reason why GroovyCollections shouldn't be part of the default whitelist, so I will open a separate issue to add that.

[mal]

I added the following line to elasticsearch.yml:

script.groovy.sandbox.receiver_whitelist: groovy.util.GroovyCollections

[dakrone]

@mal ahh okay, this is because the whitelist has to be entirely enumerated (it replaces the default whitelist, doesn't add to it), so adding that line removed the other whitelisted classes (like Object).

See: https://github.com/elasticsearch/elasticsearch/blob/b43b56a6a85f7dd131086fd83dc9267aecbbf0a3/src/main/java/org/elasticsearch/script/groovy/GroovySandboxExpressionChecker.java#L90-L111

I think this does need to be clarified in the docs, and it would be nice to have the functionality of both (replacing and adding to the whitelist).

[dakrone]

Opened #7089 for adding the GroovyCollections class to the whitelist.

[mal]

Ahh ok, is there any disadvantage to disabling the sandbox given dynamic scripting is already off and that an attacker would already need root access to edit installed scripts? If not I'll probably just do that for now.

Thanks for your help!

[dakrone]

Ahh ok, is there any disadvantage to disabling the sandbox given dynamic scripting is already off and that an attacker would already need root access to edit installed scripts? If not I'll probably just do that for now.

Yea, you can do this, disable the sandbox and since dynamic scripting is disabled by default, you'll just have to put it on disk.

I'll treat this issue as an issue to update the docs, thanks for the report!