Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
- Create (in that Database) Java Plugins (currently
Functions/Procedures, but someday Aggregates and VTIs)
Can you explain what this means, what security issue are you trying to
address?
I'm concerned about being able to exploit security holes in code not
supplied by Derby or the application. For instance, security holes in
the jdk classes or in other applications hosted on the same vm.
This is actually due to an extension to the SQL standard (part 13) that
Derby and other databases provide. The ability to have the EXTERNAL NAME
for a Java routine to be a method in a class without specifying an
installed jar file name. The security model provided by SQL part 13 does
provide security by only allowing routines to resolve to a specific
installed jar file and providing the USAGE privilege on installed jar files.
Derby follows a different path, basically adding an installed jar file
to derby.database.classpath implicitly grants USAGE on that jar to
PUBLIC. The ability to perform this implicit grant is, as you say,
itself under GRANT/REVOKE because one must have EXECUTE permission on
the procedure to set the database property. Then in addition the class
in external name in Derby need not come from a jar file, but can be
resolved from the vm's classpath.
So one part of the solution would be to enhance Derby to support
installed jar names in EXTERNAL NAME and to implement the USAGE
privilege, following the SQL standard (part 13).
Then to address the resolution of routines that do not specify an
installed jar name in EXTERNAL NAME Derby could change from an implictly
adding the current classpath to the database classpath to a model where
it must explictily be added. Maybe fixed tokens like:
JRE - routines can resolve to any classes that start with
java. and javax.
CLASSPATH - routines can resolve to any classes that are on the vm's
classpath
E.g.
derby.database.classpath=<unset>
- No resolution of any routines that do not specify a jar file.
derby.database.classpath=SALES.SALES_FORCAST
- Only resolve methods from SALES.SALES_FORCAST
derby.database.classpath=JRE:SALES.SALES_FORCAST
- Only resolve methods from the JRE's java. and javax. classes and
classes in SALES.SALES_FORCAST
derby.database.classpath=CLASSPATH:SALES.SALES_FORCAST
- Only resolve methods from the current classpath, excluding java.
and javax classes, and those from SALES.SALES_FORCAST
derby.database.classpath=JRE:CLASSPATH:SALES.SALES_FORCAST
- Resolve methods as 10.2.
Dan.
