Hi Kant, A common pattern in sandboxing (semi-)untrusted code* in Java processes is to make use of a SecurityManager<https://docs.oracle.com/javase/8/docs/api/java/lang/SecurityManager.html> with an associated Policy<https://docs.oracle.com/javase/8/docs/api/java/security/Policy.html>. These can be used to define a whitelist of packages permitted to be invoked by user code executed in its context.
The implementation of ThreadAwareSecurityManager and SecurityThreadGroup might be helpful as an example: – https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/security/ThreadAwareSecurityManager.java – https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/security/SecurityThreadGroup.java For Java-based UDF functions, see also the definition of the UDF bytecode verifier defined here: – https://github.com/apache/cassandra/blob/cassandra-3.11/src/java/org/apache/cassandra/cql3/functions/JavaBasedUDFunction.java#L96-L136 --- * I say (semi-) as allowing users to define and execute code within a database process implies a fairly high level of trust, and though guarded by a SecurityManager and bytecode verifier, may not be a matter to be taken lightly depending on the level of security or tenant isolation you require. On Apr 3, 2018, at 7:13 PM, Kant Kodali <[email protected]<mailto:[email protected]>> wrote: Hi All, I was reading the article below and I was wondering how did one manage to block all I/O calls given that there is no byte code instruction for I/O in java instead all the I/O calls in java will go through invokevirtual byte code instruction. But this can call a C function that just add two numbers right. so how can one block all I/O calls? Thanks! https://www.datastax.com/dev/blog/user-defined-aggregations-with-spark-in-dse-5
