groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <>
Subject RE: Security feedback request: Setting system properties via configuration settings
Date Tue, 18 Aug 2015 12:33:40 GMT
Is this limited to scripts? Looking at the docs
it doesn't say it's strictly limited to the Script class with the main method running the
application, but I've never tried to use grapes outside of this context. If @Grab works anywhere,
it could be a risky move.

I would say the set property should occur with the security privileges of annotated class,
as if that class had System.setProperty in its static constructor, if there is a SecurityManager.
I think this is important as one can run scripts as embedded Groovy script engines, and this
is a concern. I'm thinking of GroovyShell's evaluate/run method. You wouldn't want SecurityManager
to block setProperty in such a script but NOT to block it when used with @Grab. Also, even
if there is not a SecurityManager, it might be reasonable for an GroovyShell/class loader
option to block @Grab from calling setProperty, because in these cases it would not be a good
idea to modify global state when not running a dedicated JVM for the script.

That leads into a project I saw announced on this list, whose name I cannot remember now,
that was basically a Groovy script daemon to eliminate the JVM startup time by shipping the
scripts to the daemon to run. Calling setProperty for SSL or proxy purposes in that daemon
would not work, much less not be safe. In this case that daemon should be able to suppress
Grape's setProperty, even if the script might call other setProperty, and the daemon itself
should control proxy/SSL settings.


-----Original Message-----
From: Paul King [] 
Sent: Tuesday, August 18, 2015 5:27 AM
Subject: Security feedback request: Setting system properties via configuration settings

Hi folks,

We are planning to add the ability to set system properties via the @GrabConfig annotation[1].
This will allow scripts which use @Grab to access an Ivy/Maven repo via a proxy (e.g. using
system property http.proxyHost) or specify a trust certificate store (using the
system property) or set other needed system properties. This will use System.setProperty under
the covers[2], so a well-defined security mechanism is in place.

We don't see this proposed feature as creating any additional security risk since you could
just as easily add such system properties when invoking the JVM at the command-line or have
System.setProperty lines in your script - the only difference in the latter case is the timing
since @Grab does it's magic during class initialization and adds the grabbed jars to the classpath
if needed, so the properties must be set before the script is run.

While we don't believe this introduces any new risks, we thought we'd ask for wider feedback
and see if anyone else perceives any possible security risk that we might not be aware of
and allow us to modify the proposed approach[2] if needed to mitigate any such risks.

Cheers, Paul.

This email has been checked for viruses by Avast antivirus software.

This email message and any attachments are for the sole use of the intended recipient(s).
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all copies of the
original message and any attachments.
View raw message