[ 
https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468065
 ] 

Daniel John Debrunner commented on DERBY-2206:
----------------------------------------------

> It's unfortunate that having the privilege to set one database property means 
> that you have privilege to set them all.

I found out this is not true. The database owner can provide a setup where a 
user can just modify one database property, such as derby.database.classpath. 
How to do it is a liitle non-obvious now, but  it is possible. In the future it 
will become easier when "run as definer" mode is implemented for routines. So I 
think the assumption that being able to change a database property means one 
has the same powers as the database owner is an invalid one. Thus I believe 
that to add a jar file to derby.database.classpath should require USAGE 
priviledge to PUBLIC on that jar.

The "run as definer" mode I think is a good future step to resolve a number of 
the security issues such as:
  - ability to set specific database properties (e.g database owner provides a 
run as definer routine that sets a single property, and grants EXECUTE on that).
  - ability for others to shutdown a database (database owner provides a run as 
definer routine that shuts the database down).
and it's standard.

Here's the non-obvious way to provide ability for ALICE to set the database 
classpath without granting EXECUTE on SYSCS_SET_DATABASE_PROPERTY

  1) database owner creates a table with a CP_VALUE column VARCHAR(30000)
  2) database owner creates a trigger on INSERT of the table with an action of
      CALL SYSCS_SET_DATABASE_PROPERTY('derby.database.classpath', NEW.CP_VALUE)
  3) database owner grants INSERT to ALICE on the table

Now when ALICE inserts a value into the table it will be set as the database 
classpath. This takes advantage of the fact that triggers run as definer.

Optional steps are:
   4) database owner creates a one argument  procedure that inserts into the 
table
   5) database owner grants EXECUTE on the procedure to ALICE (the INSERT grant 
is still needed).

The ALICE can use something like
   CALL DBO.SET_CLASSPATH('ALICE.MYJAR');

(everything can always be solved by adding indirection :-)

The table can also track the history of who changed the class path when. I have 
a JUnit test that demonstrates this, I will commit sometime in the next couple 
of days.

> Provide complete security model for Java routines
> -------------------------------------------------
>
>                 Key: DERBY-2206
>                 URL: https://issues.apache.org/jira/browse/DERBY-2206
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security, SQL
>            Reporter: Rick Hillegas
>
> Add GRANT/REVOKE mechanisms to control which jar files can be mined for 
> user-created objects such as Functions and Procedures. In the future this may 
> include Aggregates and Function Tables also. The issues are summarized on the 
> following wiki page: http://wiki.apache.org/db-derby/JavaRoutineSecurity. 
> Plugin management can be tracked by this JIRA rather than by DERBY-2109. This 
> is a master JIRA to which subtasks can be linked.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to