Rick Hillegas (JIRA) wrote:
Dan, could you say something more about how you think we should sand-down the plugin privilege:
I did: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200611.mbox/[EMAIL PROTECTED]
8a) I agree that one of the problems is the ability to invoke code outside the jar files supplied with the application. But I think there are other issues. For instance, there may be publicly accessible methods in the application jar files which should not be called without setting up some context.
I think you are talking about the case where an installed jar file (sqlj.install_jar) has public static method(s) in public class(es) that should not be used as Java procedures or functions.
I don't think I've seen any proposal that would allow a user resolving to some methods but not to others in the same jar file. The SQL standard provides the USAGE permission at the jar file level.
The solution might just be don't do that, factor the jar files so that it only exposes methods you want exposed.
If you want I could start a wiki page with all the possibilities for where classes could be loaded from through Java routines, the security risks and how they could be covered with standard mechanisms etc. Then it should be obvious where the gaps are. You (or anyone else) could also add in other possibilities that I didn't consider or missed.
Dan.
