Is this limited to scripts? Looking at the docs http://docs.groovy-lang.org/latest/html/documentation/grape.html 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. Jason -----Original Message----- From: Paul King [mailto:[email protected]] Sent: Tuesday, August 18, 2015 5:27 AM To: [email protected]; [email protected]; [email protected] 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 javax.net.ssl.keystore 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. [1] https://issues.apache.org/jira/browse/GROOVY-7548 [2] https://github.com/apache/incubator-groovy/pull/83 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ---------------------------------------------------------------------- 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.
