[
https://issues.apache.org/jira/browse/DERBY-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12467866
]
Rick Hillegas commented on DERBY-2206:
--------------------------------------
I like the idea that Derby is secure by default. I hope this can be squared
with the community's expectations that upgrade is painless. Those, at least,
seemed to be our expectations during the last release cycle.
Let's run with your proposal that secure-by-default trumps painless-upgrade. It
looks like you are suggesting that customers opt into security when they turn
on authentication. I'm a little distressed that authentication does not imply
that the GRANT/REVOKE machinery is turned on and that we have two independent
knobs for these behaviors. We certainly need to turn both of these knobs in
order to secure Java routines as described by this JIRA. It would be better if
we had a single knob whose meaning was "run securely." Maybe the best we can
do, going forward, is say that we recognize one setting of knobs which means
"run securely" and that over time, as we plug security holes, customers who set
the knobs this way will get better default security although maybe at the cost
of some upgrade friction. Let me try to make this concrete by further refining
your proposal:
If the customer sets BOTH requireAuthentication and sqlAuthorization to true,
then:
1) Booting the network server installs a SecurityManager
2) Shutdown/upgrade/encrypt database powers are restricted to the database
owner.
3) Derby ignores the setting of derby.database.classpath and, instead, manages
security for Java routines according to the SQL standard.
If the customer fails to turn on one of these properties, then:
1') The network server fails to boot from the command line unless -unsecure is
specified.
2') Anyone who can connect to a database can shut it down, encrypt it, and
upgrade it.
3') Security for Java routines is what it was in 10.2, and Derby uses
derby.database.classpath.
> 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.
