db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2109) System privileges
Date Thu, 14 Dec 2006 17:35:23 GMT
    [ http://issues.apache.org/jira/browse/DERBY-2109?page=comments#action_12458563 ] 
            
Daniel John Debrunner commented on DERBY-2109:
----------------------------------------------

>> 3) Plugin scope. I think that you and Dan agree that "plugin" is a
>>    database-specific, not a system-wide privilege. My first reaction
>>    (still recorded in the description block for this JIRA) also
>>    listed "plugin" as a database-wide privilege. I can argue the
>>    issue both ways. On the one hand, the "plugin" power potentially
>>    gives the user the ability to expose/exploit code which has
>>    system-wide effects. On the other hand, the affected objects
>>    (jars, functions, procedures) are all scoped to the database
>>    level. I am happy to treat "plugin" as a database-specific
>>    privilege.
> 
> I see your point, but I do not think many organizations will find it
> practical to deny database owners to be able to create plugins.
> Hence, you might as well make it a database-specific feature.

I would actually say you aleady have the system level ability, because the actions of any
java code is controlled by the installed security manager and policy which is set at a system
level. Thus the ability to create Java routines should be controlled at the datbaase level
and the ultimate power of those routines is controlled at the system level.

> System privileges
> -----------------
>
>                 Key: DERBY-2109
>                 URL: http://issues.apache.org/jira/browse/DERBY-2109
>             Project: Derby
>          Issue Type: New Feature
>          Components: Security
>    Affects Versions: 10.3.0.0
>            Reporter: Rick Hillegas
>             Fix For: 10.3.0.0
>
>         Attachments: systemPrivs.html
>
>
> Add mechanisms for controlling system-level privileges in Derby. See the related email
discussion at http://article.gmane.org/gmane.comp.apache.db.derby.devel/33151.
> The 10.2 GRANT/REVOKE work was a big step forward in making Derby more  secure in a client/server
configuration. I'd like to plug more client/server security holes in 10.3. In particular,
I'd like to focus on  authorization issues which the ANSI spec doesn't address.
> Here are the important issues which came out of the email discussion.
> Missing privileges that are above the level of a single database:
> - Create Database
> - Shutdown all databases
> - Shutdown System
> Missing privileges specific to a particular database:
> - Shutdown that Database
> - Encrypt that database
> - Upgrade database
> - Create (in that Database) Java Plugins (currently  Functions/Procedures, but someday
Aggregates and VTIs)
> Note that 10.2 gave us GRANT/REVOKE control over the following  database-specific issues,
via granting execute privilege to system  procedures:
> Jar Handling
> Backup Routines
> Admin Routines
> Import/Export
> Property Handling
> Check Table
> In addition, since 10.0, the privilege of connecting to a database has been controlled
by two properties (derby.database.fullAccessUsers and derby.database.defaultConnectionMode)
as described in the security section of the Developer's Guide (see http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message