db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (JIRA)" <derby-...@db.apache.org>
Subject [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
Date Fri, 04 Aug 2006 20:46:14 GMT
     [ 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

        

Mime
View raw message