Re: Groovy sandboxing

Paolo Di Tommaso <[email protected]> Sun, 2 Aug 2026 14:52:43 +0200
Newsgroups gmane.comp.lang.groovy.user
Message-ID <CADgKzdz6WN6WPf=zSTXxrGdJ6U1gpXmseTtLO=hShVS8iuT6hQ@mail.gmail.com>
--000000000000fb930106580fe77b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Leaving an exhaustive reply to core maintainers however I believe that
would require running Groovy on Truffle (Graal polyglot API).

That would be cool, but I see no plan in that direction.


Paolo

On Sat, Aug 1, 2026 at 11:34=E2=80=AFPM ski n <[email protected]> wr=
ote:

> Groovy has always been a powerful scripting language. Now with agents (fo=
r
> example created with Spring AI or Langchain4j) it's becoming
> more common to run Groovy scripts from for example Java or Kotlin.
>
> The question is when third-party generated scripts from agents (or just a
> script written by other developers)
> run these scripts, how to run it safely and securely? For example by not
> giving it access to the file system, socket or environment.
>
> I recently read the documentation of GraalVM on sandboxing:
>
> https://www.graalvm.org/latest/security-guide/sandboxing/
>
> There you can have guest code (JavaScript, Python, Wasm etc) that is a
> sandbox when started from the JVM/GraalVM. This works because guest
> languages
> run in a separate VM, truffle VM, where these restriction policies can be
> applied.
>
> Groovy as being a JVM language itself, runs natively on the JVM, and is
> very much integrated with other JVM languages such as Java. Historically
> there have been several approaches to run Groovy restrictly such as:
>
> SecureASTCustomizer
> custom classloaders
> SecurityManager (now removed from Java)
> bytecode rewriting
> custom compilation restrictions
>
> Unfortunately, after the removal of the Java Security Manager, there is n=
o
> robust, built-in JVM mechanism for securely sandboxing arbitrary Groovy
> code.
>
> Are there any plans to allow strong sandboxing for Groovy embedded in
> another JVM Language?
>
> Raymond
>

--000000000000fb930106580fe77b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Leaving an exhaustive reply to core maintainers however I =
believe that would require running Groovy on Truffle (Graal polyglot API).=
=C2=A0<div><br></div><div>That would be cool, but I see no plan in that dir=
ection.=C2=A0</div><div><br></div><div><br></div><div>Paolo</div></div><br>=
<div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"=
gmail_attr">On Sat, Aug 1, 2026 at 11:34=E2=80=AFPM ski n &lt;<a href=3D"ma=
ilto:[email protected]">[email protected]</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>Groovy has always been a powerful scripting language. Now with agents (fo=
r example created with Spring AI or Langchain4j) it&#39;s becoming<br>more =
common to run Groovy scripts from for example Java or Kotlin.=C2=A0<br><br>=
The question is when third-party generated scripts from agents (or just a s=
cript written by other developers)<br>run these scripts, how to run it safe=
ly and securely? For example by not giving it access to the file system, so=
cket or environment.<br><br>I recently read the documentation of GraalVM on=
 sandboxing:<br><br><a href=3D"https://www.graalvm.org/latest/security-guid=
e/sandboxing/" target=3D"_blank">https://www.graalvm.org/latest/security-gu=
ide/sandboxing/</a><br><br>There you can have guest code (JavaScript, Pytho=
n, Wasm etc) that is a sandbox when started from the JVM/GraalVM. This work=
s because guest languages<br>run in a separate VM, truffle VM, where these =
restriction policies can be applied.<br><br>Groovy as being a JVM language =
itself, runs natively on the JVM, and is very much integrated with other JV=
M languages such as Java. Historically there have been several approaches t=
o run Groovy restrictly such as:<br><br>SecureASTCustomizer<br>custom class=
loaders<br>SecurityManager (now removed from Java)<br>bytecode rewriting<br=
>custom compilation restrictions<br><br>Unfortunately, after the removal of=
 the Java Security Manager, there is no robust, built-in JVM mechanism for =
securely sandboxing arbitrary Groovy code.<br><br>Are there any plans to al=
low strong sandboxing for Groovy embedded in another JVM Language?<br><br><=
/div>Raymond</div>
</blockquote></div>

--000000000000fb930106580fe77b--