You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Mamta A. Satoor (JIRA)" <de...@db.apache.org> on 2006/08/04 22:46:14 UTC

[jira] Updated: (DERBY-1643) As per the functional spec attached to DERBY-1330, a "revoke execute ... restrict" should fail if there are dependent objects on the execute privilege

     [ http://issues.apache.org/jira/browse/DERBY-1643?page=all ]

Mamta A. Satoor updated DERBY-1643:
-----------------------------------

    Attachment: DERBY1643_diff_V1_RevokeExecutePrivilege.txt
                DERBY1643_stat_V1_RevokeExecutePrivilege.txt

Here is the next incremental patch(DERBY1643_diff_V1_RevokeExecutePrivilege.txt) for revoke privileges related to routines. The o/p of svn stat -q is attached as DERBY1643_stat_V1_RevokeExecutePrivilege.txt. Also, derbyall ran fine with Sun's jdk 1.4 on Windows XP platform.

In Derby, the execute permission on a routine can't be revoked as long as there are dependent objects relying on that permissions. This patch implements that behavior by adding a new revoke invalidation action REVOKE_EXECUTE_PRIVILEGE, just for routine revoke. This invalidation gets sent when a revoke execute is issued. When dependents, a ViewDescriptor and/or a TriggerDescriptor, get this invalidation action, they will raise error that revoke execute can't be performed because there is a dependent object on that permission.

In general, there can be 3 kind of persistent dependents on a permission. They are namely, a ViewDescriptor, a TriggerDescriptor, and a ConstraintDescriptor. But in Derby, a constraint can't use a routine and hence a constraint can't possibly depend on execute privilege. If ever, for some unknown reason(bug), a ConstraintDescriptor will receive REVOKE_EXECUTE_PRIVILEGE, Derby will end up throwing an exception saying that revoke execute can't be performed because there is a dependent object on it.


Test changes
1)Have a view depend on the execute routine privilege. "Revoke execute ... restrict" will fail as long as the view exists. Once the view is dropped, since there are no more dependents on execute routine privilege, "Revoke execute ... restrict" will pass.
2)Similar test for trigger. If trigger is relying on a execute routine privilege, then that privilege can't be revoked as long as trigger is still around. After the trigger is dropped, execute routine privilege can be revoked.
3)In addition, I added a test which is not directly related to revoke routine work. Just an additional test for grant revoke. In this test, I have couple triggers on a single table depend on different privileges. When a privilege is revoked, only the
affected triggers get dropped, the rest of the triggers should remain still active.

> As per the functional spec attached to DERBY-1330, a "revoke execute ... restrict" should fail if there are dependent objects on the execute privilege
> ------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1643
>                 URL: http://issues.apache.org/jira/browse/DERBY-1643
>             Project: Derby
>          Issue Type: New Feature
>          Components: SQL
>    Affects Versions: 10.2.0.0
>            Reporter: Mamta A. Satoor
>         Assigned To: Mamta A. Satoor
>         Attachments: DERBY1643_diff_V1_RevokeExecutePrivilege.txt, DERBY1643_stat_V1_RevokeExecutePrivilege.txt
>
>
> As per the functional spec attached to DERBY-1330, a "revoke execute ... restrict" should fail if there are dependent objects on the execute privilege
> In order to implement this, when revoke execute is executed, a special invalidation action should be sent and dependent objects will need to catch that invalidation and throw an exception. If there are no dependents, then no exception will be thrown and revoke execute will succeed.
> I am just creating a new jira entry here so it is easier to track sub items of DERBY-1330. Will link this Jira entry to DERBY-1330. 

-- 
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