db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-2109) System privileges
Date Tue, 12 Dec 2006 21:20:26 GMT
Daniel John Debrunner wrote:
> 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

Thanks, Dan. I did not see this mail earlier. I'm happy with this 
solution: Allow external function names to be qualified by jar file 
names and then use GRANT/REVOKE to manage USAGE privilege on the jar 
files. In the future, this should work for VTIs since they are just a 
special kind of function. We can make this work for 
user-defined-aggregates too if we choose the right syntax for declaring 

Perhaps rather than inventing new syntax, we could model the special 
package clusters (JRE and CLASSPATH) as pseudo-jars in the SYS schema. 
So for instance


>> 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.
I think this is fine.
> 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.
Thanks for volunteering to start a wiki page. That would be very helpful.


View raw message