Hi Rick:

For new feature, I think DERBY-464 (Grant and revoke support) can be closed once its remaining subtask DERBY-1330 and documentation (DERBY-1646) is completed. 

As for bug fixes, the following 8 issues should go into 10.2 as I think they are important fixes for grant and revoke functionality as a whole(some of these JIRA issues already have patches available):

DERBY-1686  Grant/Revoke: Attempt to GRANT access to another user on a VIEW, created by the current user with only SELECT privilege on the base table does not fail.
DERBY-1708  Unprivileged user can perform lock table statement on a table which he/she does not have any access rights (patch available)
DERBY-1538  Unexpected behavior on self privilege revocation  (patch available)
DERBY-1582  REVOKE statement does not generate a warning when no privileges are revoked. (patch available)
DERBY-1583  With grant revoke enabled, defining a trigger whose actions updates a table (from different schema) results in NPE
DERBY-1589  CREATE TABLE throws NullPointerException in Derby SQL Standard Authorization after DROPs and REVOKES
DERBY-1724  Executing grant statement within a transaction leads to a NPE later when the db owner attempts to update a table

Note:  Some of the NPE issues above maybe related to what Bryan found this morning with the alter table testcase with derby.database.sqlAuthorization turned on.

In my opinion, I would like to see the above get fixed in 10.2 release but I'll leave it to the community to decide/vote what should go into 10.2 base.  =)


Yip


On 8/23/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
Hi Yip,

Thanks for the analysis. Only one of these issues (1686) turns up on our
lists of Blocker and Urgent features which gate 10.2. I suspect that's
an oversight. In your opinion, which of these issues must be fixed
before we release 10.2?

Thanks,
-Rick

Yip Ng wrote:

> Here is a summary of the remaining open or in-progress JIRA issues for
> DERBY-464 (Grant and Revoke).  It would be good to start cleaning them
> up if some of these issues have already been resolved to see where
> DERBY-464 currently is at.
>
>
> New Feature:
> DERBY-1539  A trigger should be dropped when a privilege required by
> the trigger is revoked.
> DERBY-1611  A view should be dropped when a privilege required by the
> view is revoked.
> DERBY-1612  A constraint should be dropped when a privilege required
> by the constraint is revoked.
> DERBY-1643  A "revoke execute ... restrict" should fail if there are
> dependent objects on the execute privilege
> DERBY-1646  Documentation to address Grant/Revoke Authorization for
> views/triggers/constraints/routines(DERBY-1330)
>
> Bug:
> DERBY-1538  Unexpected behavior on self privilege revocation
> DERBY-1582  REVOKE statement does not generate a warning when no
> privileges are revoked.
> DERBY-1583  With grant revoke enabled, defining a trigger whose
> actions updates a table (from different schema) results in NPE
> DERBY-1589  CREATE TABLE throws NullPointerException in Derby SQL
> Standard Authorization after DROPs and REVOKES
> DERBY-1686  Grant/Revoke: Attempt to GRANT access to another user on a
> VIEW, created by the current user with only SELECT
>                      privilege on the base table does not fail
> DERBY-1708  Unprivileged user can perform lock table statement on a
> table which he/she does not have any access rights
> 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 from a trigger should
>                      fail.
>
> Sub-task:
> DERBY-1330  Provide runtime privilege checking for grant/revoke
> functionality
>
> Task:
> DERBY-1522  Switch(if supported) from Derby Authorization to Derby SQL
> Standard Authorization needs to be tested
>
> Improvement:
> DERBY-1521  Upgrade test needs to be enhanced to test grant revoke
>


Reply via email to