I think I found the article I was referring to:
https://www.compose.com/articles/elasticsearch-security-update-groovy-scripting-dropped/
(2015-03):
"After talking with the Groovy developers, Elasticsearch have decided
that Groovy will never be sufficiently safe in a sandbox and have
removed it from the list of sandboxed languages."
( I have used Solr, but not Elasticsearch. It seems they now have
"Painless", a Groovy-subset-compatible language as their main scripting
language:
https://www.elastic.co/guide/en/elasticsearch/painless/6.2/painless-specification.html
... )
On 01.04.2018 20:15, Jochen Theodorou wrote:
On 01.04.2018 19:58, MG wrote:
Hi Jochen,
I just thought about some post by another project I read some time
back (alas I can no longer remember which project exactly) which used
Groovy as its scripting language, but switched to a lesser, more
restrictive scripting option, because they needed to make the
scripting more secure, which, according to the post, could not be
done using Groovy "because of all the reflection Groovy uses". So I
was wondering if changes at a fundamental level in Groovy seem
unavoidable, if it would make sense to also keep the security aspect
in mind ?
In my opinion that project is wrong, because the security manager
mechanisms provide enough protection. The problem is that rarely
anyone can use a security manager properly. Anyway... Groovy won't be
able to do any call Java cannot do in principle in this version. That
is not because of keeping security in mind, that is more because of
the module system, that enforces this
Whatever the reason it will be more secure, my line of thought was, that
if some (clever) way to work around this exists, to maybe still not go
along that route, even though I don't like to see this feature go and
people who use this in tests will surely miss it...
(Of course that argument is mute if they could have fixed their problem
through proper security manager use).
Cheers,
mg
