Daniel John Debrunner wrote: > Creating an external routine would have all sorts of security concerns > for a database owner, it's allowing a remote user to execute code on > their system.
I thought of a fairly clean solution for this in the 10.2 timeframe: Allow creation of Java routines (functions & procedures). 1) Allow execution of Java routines that that map directly to a public static method in the Java system libraries, package in EXTERNAL NAME clause starting with 'java.' or 'javax.'. This is fine because the Java libraries are assumed to be secure and the class invoking the method will have no permissions so nothing bad can be done by a remote user. 2) Allow execution of Java routines that map into a public static method loaded from a jar file installed into the database using sqlj.install_jar. This is ok because the database owner must have granted permission to install the jar and set the database classpath so they showed they trusted the user already. 3) Disallow execution of any other Java routines. This would be routines that map to Java methods from the JVM's classpath or other non-database class loading mechanism. Maps to the 'external routine' concept in other databases. Future system/database wide privileges could enable this selectively. I'm going to be making changes in this area anyway, so I'll spend some time seeing how easy this is. Dan.
