Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Tue, 12 Dec 2006 13:20:26 -0800
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: [jira] Commented: (DERBY-2109) System privileges
In-reply-to: <457E011C.9000206@apache.org>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <457F1D1A.4070906@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=UTF-8
Content-transfer-encoding: 7BIT
References: <19307824.1165881921616.JavaMail.jira@brutus>
 <457E011C.9000206@apache.org>
User-Agent: Thunderbird 1.5.0.5 (X11/20060828)

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 
udas.

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

derby.database.classpath=SYS.CLASSPATH:SALES.SALES_FORECAST

>>
>> 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.

Regards,
-Rick