| Key: |
DERBY-464
|
| Type: |
Improvement
|
| Status: |
Closed
|
| Resolution: |
Fixed
|
| Priority: |
Major
|
| Assignee: |
Unassigned
|
| Reporter: |
Satheesh Bandaram
|
| Votes: |
2
|
| Watchers: |
0
|
|
If you were logged in you would be able to see more operations.
|
|
|
Time Tracking:
Issue & Sub-Tasks
Issue Only
Issue & Sub-Tasks
Issue Only
|
|
|
|
File Attachments:
|
|
|
Environment:
|
generic
|
|
Issue Links:
|
Incorporates
|
|
This issue incorporates:
|
|
DERBY-1523
Statements in cache need to depend on privileges and the appropriate statements in cache should get invalidated if those privileges change.
|
|
|
|
 |
DERBY-1521
Upgrade test needs to be enhanced to test grant revoke
|
|
|
|
|
|
DERBY-1367
add lang/grantrevoke.java to derbynetclientmats
|
|
|
|
|
|
DERBY-1579
Remove SYS.SYSREQUIREDPERM from Derby 10.2. This was added for Grant Revoke functionality
|
|
|
|
|
DERBY-1522
Switch(if supported) from Derby Authorization to Derby SQL Standard Authorization needs to be tested
|
|
|
|
|
|
Reference
|
|
This issue relates to:
|
|
|
|
|
|
|
|
DERBY-1716
Revoking select privilege from a user times out when that user still have a cursor open.
|
|
|
|
|
|
DERBY-1724
Executing grant statement within a transaction leads to a NPE later when the db owner attempts to update a table
|
|
|
|
|
|
DERBY-1729
Invoking Java stored procedure that contains GRANT or REVOKE statement with CONTAINS SQL should fail.
|
|
|
|
|
|
DERBY-1583
With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE
|
|
|
|
|
|
DERBY-1708
Unprivileged user can perform lock table statement on a table which he/she does not have any access rights
|
|
|
|
|
|
DERBY-1723
Database owner revokes select privilege from a schema owner but owner is still able to select
|
|
|
|
|
|
DERBY-1738
An user is able to grant select privilege on a view but the underlying object is not own by the user.
|
|
|
|
|
|
DERBY-1542
Implicit revoke via drop table does not clean up its associated row(s) in SYS.SYSTABLEPERMS
|
|
|
|
|
|
DERBY-1847
SELECT statement asserts with XJ001 when attempted to select a newly added column in SQL authorization mode
|
|
|
|
|
|
DERBY-1715
Revoke fails when grantee declares additional view that is on top of the view to be dropped
|
|
|
|
|
|
DERBY-1538
Unexpected behavior on self privilege revocation
|
|
|
|
|
|
DERBY-1592
Update statement is allowed to execute even though the column that the statement access has been revoked.
|
|
|
|
|
|
DERBY-1582
REVOKE statement does not generate a warning when no privileges are revoked.
|
|
|
|
|
|
This issue is related to:
|
|
DERBY-1523
Statements in cache need to depend on privileges and the appropriate statements in cache should get invalidated if those privileges change.
|
|
|
|
|
DERBY-1589
CREATE TABLE throws NullPointerException in Derby SQL Standard Authorization after DROPs and REVOKES
|
|
|
|
|
|
|
| Urgency: |
Normal
|
| Resolution Date: |
18/Sep/06 03:44 PM
|
|
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.
|
|
Description
|
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.
|
Show » |
| No work has yet been logged on this issue.
|
|
