[ http://issues.apache.org/jira/browse/DERBY-464?page=all ]
Satheesh Bandaram updated DERBY-464:
------------------------------------
Attachment: grantRevokeSpec_v2.html
I have updated Grant Revoke functional specification with newer version.
Changes from previous version are highlighted in RED. Main changes from
previous version are:
1) Added a new table showing detailed information on system routines... Who can
execute and what other privileges are required. I am in two minds about whether
everyone (who has owns their tables) should be able to invoke import/export
routines or not, BY DEFAULT. Since import/export routines access input/output
files on the server-side, I am not sure if everyone should be able to execute
these, BY DEFAULT. So I am currently proposing DBA needs to grant EXECUTE
privilege to be able to invoke them.
2) Clarified what was discussed on the list about who owns system schemas. I am
going to be changing authorizationID of system schemas from psuedo user 'DBA'
to authorizationID of database creator or to the authorizationID of the user
who invokes full upgrade.
3) Previous version of the spec was wrong about default EXTERNAL SECURITY
clause and what SQL Standard says about it. SQL standard says default EXTERNAL
SECURITY, if not specified, is implementation defined. Previous version of the
spec and myself thought default value as specified by SQL standard was DEFINER,
so I proposed adding DEFINER/INVOKER clause to routines now so we don't
introduce forward compatibility issues by keeping INVOKER model. But the spec
is very clear about default value of SECURITY, so there is no need to implement
that feature NOW.
Let me know if anyone have any comments.
> Enhance Derby by adding grant/revoke support. Grant/Revoke provide finner
> level of privileges than currently provided by Derby that is especially
> useful in network configurations.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-464
> URL: http://issues.apache.org/jira/browse/DERBY-464
> Project: Derby
> Type: New Feature
> Components: SQL
> Versions: 10.0.2.1, 10.1.1.0, 10.2.0.0
> Environment: generic
> Reporter: Satheesh Bandaram
> Assignee: Satheesh Bandaram
> Attachments: GrantRevokePartII.stat, GrantRevokePartII.txt,
> GrantRevokePartII.txt, changeDescriptionPartII, grantRevoke.patch.Dec5,
> grantRevoke.stat.Dec5, grantRevokeSpec.html, grantRevokeSpec_v2.html
>
> Derby currently provides a very simple permissions scheme, which is quite
> suitable for an embedded database system. End users of embedded Derby do not
> see Derby directly; they talk to a application that embeds Derby. So Derby
> left most of the access control work to the application. Under this scheme,
> Derby limits access on a per database or per system basis. A user can be
> granted full, read-only, or no access.
> This is less suitable in a general purpose SQL server. When end users or
> diverse applications can issue SQL commands directly against the database,
> Derby must provide more precise mechanisms to limit who can do what with the
> database.
> I propose to enhance Derby by implementing a subset of grant/revoke
> capabilities as specified by the SQL standard. I envision this work to
> involve the following tasks, at least:
> 1) Develop a specification of what capabilities I would like to add to Derby.
> 2) Provide a high level implementation scheme.
> 3) Pursue a staged development plan, with support for DDL added to Derby
> first.
> 4) Add support for runtime checking of these privileges.
> 5) Address migration and upgrade issues from previous releases and from old
> scheme to newer database.
> Since I think this is a large task, I would like to invite any interested
> people to work with me on this large and important enhancement to Derby.
--
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
