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 "Dyre Tjeldvoll (JIRA)" <ji...@apache.org> on 2007/05/01 14:13:15 UTC

[jira] Commented: (DERBY-2594) Revoking a privilege from an SQL Object should invalidate statements dependent on that object

    [ https://issues.apache.org/jira/browse/DERBY-2594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12492867 ] 

Dyre Tjeldvoll commented on DERBY-2594:
---------------------------------------

I added some trace to see what happens when a REVOKE is received
by RoutinePrivilegeInfo. I added the following to
BasicDependencyManager.coreInvalidate():

 @@ -300,6 +302,16 @@
 
                                Dependent dep = dependency.getDependent();
 
+                               if (p instanceof AliasDescriptor && 
+                                       action == INTERNAL_RECOMPILE_REQUEST &&
+                                       dep instanceof GenericPreparedStatement) {
+                                       System.out.println
+                                               ("REVOKE on "+
+                                                ((AliasDescriptor)p).getObjectName()+
+                                                " sends recompile to `"+
+                                                ((GenericPreparedStatement)dep).statement.getSource()+"'");
+                               }
+
                                if (affectedCols != null)

Running lang.GrantRevokeDDLTest then produces the following output:

[...]
REVOKE on F_ABS1 sends recompile to ` select * from v24'
REVOKE on F_ABS1 sends recompile to ` create view v24 as select * from mamta1.v11'
REVOKE on F_ABS1 sends recompile to ` select * from v11'
REVOKE on F_ABS1 sends recompile to ` create view v11(c111) as values mamta1.f_abs1(-5)'
REVOKE on F_ABS1 sends recompile to ` values f_abs1(-5)'
REVOKE on SELECTFROMSPECIFICSCHEMA sends recompile to `revoke execute on function selectFromSpecificSchema from mamta3 restrict'
REVOKE on SELECTFROMSPECIFICSCHEMA sends recompile to ` grant execute on function selectFromSpecificSchema to mamta3'
REVOKE on F_ABS sends recompile to ` revoke execute on function f_abs from randy restrict'
REVOKE on F_ABS sends recompile to ` grant execute on function f_abs to randy'
REVOKE on F_ABS2 sends recompile to `revoke execute on function F_ABS2 from user2 restrict'
REVOKE on F_ABS2 sends recompile to `grant execute on function F_ABS2 to user2'
REVOKE on F_ABS2 sends recompile to `values user1.F_ABS1(10) + user1.F_ABS2(-10)'
REVOKE on F_ABS1 sends recompile to ` revoke execute on function F_ABS1 from user2 restrict'
REVOKE on F_ABS1 sends recompile to `values user1.F_ABS1(-8)'


which looks correct to me. So unless I hear otherwise, I'll start
making my preliminary patch ready for commit.

> Revoking a privilege from an SQL Object should invalidate statements dependent on that object
> ---------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2594
>                 URL: https://issues.apache.org/jira/browse/DERBY-2594
>             Project: Derby
>          Issue Type: Improvement
>          Components: SQL
>    Affects Versions: 10.2.1.6
>            Reporter: Dyre Tjeldvoll
>         Assigned To: Dyre Tjeldvoll
>         Attachments: revoke_prelim.diff
>
>
> Revoking a privilege on a table will currently cause the DependencyManager.invalidateFor() to be called on the table's TablePermsDescriptor with the action=REVOKE_PRIVILEGE. However, the prepared statements that refer to that table are dependents of the table's TableDescriptor, but NOT its TablePermsDescriptor, so the statements are not invalidated after revoke.
> This problem is currently hidden by the fact that authorization is checked on every execution, but this will change when language result sets are no longer reused (see DERBY-827). 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.