Dag H. Wanvik wrote:
Thanks for starting this discussion, Rick, I am also interested in
looking at this.
Rick Hillegas <[EMAIL PROTECTED]> writes:
Thanks, Dag!
...
Missing privileges that are above the level of a single database:
- Create Database
- Shutdown System
Do we need a privilge for bootAll? BTW, I am not sure how bootAll
property is supposed to work, I could not find it documented.
Agreed. I've added this to the list in DERBY-2109.
Missing privileges specific to a particular database:
- Connect to that Database
- Shutdown that Database
- Create (in that Database) Java Plugins (currently
Functions/Procedures, but someday Aggregates and VTIs)
Maybe a separate privilege to upgrade a database would be desirable,
at least hard upgrade. And a privilege to encrypt/re-encrypt a
database?
Agreed. I've added this to the list in DERBY-2109 also.
I assume the new database level system privileges will that require
SQL authorization mode is active, not just the connection
authorization, or...? In a way they are orthogonal, since system
privileges are not defined by SQL. If bundled the name
(derby.database.sqlAuthorization) would be slightly misleading..
My mind is trending that way too: GRANT/REVOKE would be a natural way to
control the per-database privileges even though it would be an extension
to the ANSI spec. Other databases use GRANT/REVOKE to control these
sorts of non-ANSI privileges. I could talk myself into extending the
meaning of derby.database.sqlAuthorization to embrace these non-ANSI
privileges: the mechanism (GRANT/REVOKE) is ANSI even though the
specific privileges aren't.
The new system level system privileges (e.g. shutdown), would they
also be enabled by SQL authorization mode?
Dag
I will try to collect my thoughts on this topic and circulate them later
today.
Thanks!
-Rick
