[
https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468401
]
Rick Hillegas commented on DERBY-2206:
--------------------------------------
I'm afraid I don't see the need for maintaining two independent ways to manage
java routine security. I think that's going to confuse users. I think there
should be one way to do this, it should be straightforward, and, if possible,
it should adhere to a standard that someone has thought through carefully. I am
worried about overloading the meaning of USAGE via on-the-fly designs. The
following makes sense to me as the single, straightforward way to manage java
routine security:
1) derby.database.classpath is not set. As soon as you set this property, you
blow a hole in your security because, now, any entry point on the system
classpath can be called out-of-context.
2) The DBA role retains exclusive power to run
SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY. This prevents derby.database.classpath
from being set.
3) The only way to declare usable procedures/functions is to use the SQL
Standard syntax, including jar ids, USAGE privilege, and jar-specific
classpaths.
That's a very clever technique you discovered for granting privilege to set
properties on a per-property basis. However, to me it looks like a sneaky way
to subvert security. Customers should be discouraged form opening that kind of
security hole.
> 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.
