On 2025/08/17 08:19:24 Tommy Svensson wrote: > Hmm ... how about educating your developers in what can be called, and what > shouldn't ? As far as I know there are very few or no software languages that > supports such things. All that is needed is experience, experience, and > experience!
I realize that the use case could not be clear to everyone. So we have an organization somewhere (US company, Finnish university, whatever) which uses Apache Syncope to build their own IAM system. In one of the many identity flows they need, they realize that the options offered by the system are not sufficient to cover their bizarre use case where - for example - the email address shall be calculated based on the first 3 letters of surname + even letters of the first name + eye color + hair color + an ordinal based on the timezone + some random letters. In such use cases, they have the chance to decorate the provisioning process by writing down a Java or a Groovy implementation of an interface, and loading such class into the system. * When it is Java, that shall be part of their Syncope-based project codebase, is likely to go through a review process and will finally require a redeploy to become effective. Also important, every adjustment will require again to go through the same, redeploy included. * When it is Groovy, an administrator with enough entitlements can load the class definition through the web UI and have it immediately available. Every change to the class will be done again via a fancy syntax-highlighted textarea. This latter administrator is not exactly one of "our developers", but someone which was granted by the organization as above to operate on the system. Hope this clarifies. Regards. > Tommy Svensson > to...@natusoft.se (mailto:to...@natusoft.se) > > På 17 augusti 2025 till 09:12:09, Francesco Chicchiriccò (ilgro...@apache.org > (mailto:ilgro...@apache.org)) skrev: > > > Hi Paul, > > thank you for your answer. > > > > About sandbox, what do you think about [3] or [4]? Both seems to be quite > > active, license-compliant and available from Maven Central. > > > > Also, do you have any example of ImportCustomizer / SecureASTCustomizer to > > start from? I have only found [5] so far. > > > > Regards. > > > > [3] https://github.com/dalet-oss/groovy-sandbox > > [4] https://github.com/craftercms/groovy-sandbox > > [5] > > https://github.com/jenkinsci/script-security-plugin/blob/master/src/main/java/org/jenkinsci/plugins/scriptsecurity/sandbox/groovy/RejectASTTransformsCustomizer.java > > > > On 2025/08/16 21:31:36 Paul King wrote: > > > Step 4 in your reference [2] is the key. > > > > > > You can provide an ImportCustomizer and a SecureASTCustomizer to limit > > > imports and prohibit statements like "System.exit()". As mentioned in that > > > article, that doesn't stop folks potentially using reflection or other > > > tricks to execute the exit() statement. You can start trying to lock down > > > such statements too. It becomes increasingly tricky to block all of the > > > tricks without crippling what your users may legitimately want to execute. > > > So, having a sandbox is the next step. > > > > > > Using the security manager with a policy file, also mentioned in that > > > reference, has gone out of vogue and isn't supported in the latest JDKs. > > > You'd more typically use a VM these days and set up a machine where it > > > didn't matter if a script somehow managed to read the /etc/passwd file (or > > > whatever). > > > > > > We have been meaning to document best practices for a sandbox environment > > > but haven't found the cycles yet. We'd be super keen to work with you to > > > write something up if you make progress. > > > > > > Cheers, Paul. > > > > > > > > > On Sat, Aug 16, 2025 at 5:13 PM Francesco Chicchiriccò > > > <ilgro...@apache.org> > > > wrote: > > > > > > > Hi team, > > > > Syncope is offering the possibility to extend / customize the base > > > > behavior on every deployment by allowing to provide custom > > > > implementations > > > > of a few Java interfaces; such implementations can be provided either as > > > > Java or Groovy classes [1], with the latter being particularly > > > > attractive > > > > as the machinery is set for runtime reload. > > > > > > > > I was wondering if there is any best-practice available to limit what > > > > could be done by Groovy classes (e.g. System.exit, spawning new > > > > processes, > > > > etc.). > > > > I found [2] and a few other references which looks anyway either old or > > > > not for general purpose. > > > > > > > > Can you suggest something else? > > > > > > > > TIA > > > > Regards. > > > > > > > > [1] > > > > https://syncope.apache.org/docs/4.0/reference-guide.html#implementations > > > > [2] > > > > https://levelup.gitconnected.com/secure-groovy-script-execution-in-a-sandbox-ea39f80ee87 > > > > > > > > -- > > > > Francesco Chicchiriccò > > > > > > > > Tirasa - Open Source Excellence > > > > http://www.tirasa.net/ > > > > > > > > Member at The Apache Software Foundation > > > > Syncope, Cocoon, Olingo, CXF, OpenJPA > > > > https://about.me/ilgrosso > > > > > > > > > > > >
