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/%3c456C88DC.8080009@apache.org%3e
>
> 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.
|