[
https://issues.apache.org/jira/browse/DERBY-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6434:
---------------------------------
Attachment: derby-6434-02-ac-correctDeletePrivs.diff
Attaching derby-6434-02-ac-correctDeletePrivs.diff. This patch corrects
privilege checking for DELETE statements. I will run regression tests. It's
likely that the tests will disclose some problems.
The approach here is to add privilege checks only when compiling the WHERE
clause of the DELETE statement. To accomplish this, the patch introduces two
new concepts:
1) Scope tracking - The compiler is given the capability to track what kind of
clause it is processing. Currently, the compiler can analyze what's going on
inside nodes BELOW the current node. This patch adds the capability to track
what's going on ABOVE the current node. The patch gives the compiler the
ability to record when it enters and leaves a particular scope. The patch adds
the following new methods to CompilerContext:
{noformat}
/**
* Record that the compiler is entering a named scope. Increment the
* depth counter for that scope.
*/
public void beginScope( String scopeName );
/**
* Record that the compiler is exiting a named scope. Decrement the
* depth counter for that scope.
*/
public void endScope( String scopeName );
/**
* Get the current depth for the named scope. For instance, if
* we are processing a WHERE clause inside a subquery which is
* invoked inside an outer WHERE clause, the depth of the whereScope
* would be 2. Returns 0 if the compiler isn't inside any such scope.
*/
public int scopeDepth( String scopeName );
{noformat}
2) Scope filtering - A new VisitableFilter is added: ScopeFilter. This filter
passes nodes only if the compiler is operating within a named scope.
I think that we may be able to use this general scope tracking to eliminate the
more limited scope tracking implemented by the following CompilerContext
methods...
{noformat}
int getReliability();
void setReliability(int reliability);
{noformat}
...but that improvement falls outside the boundaries of this JIRA.
In addition, I think that scope tracking can be used by other AST Visitors
which need to be aware of how nodes nest. In particular, scope tracking may be
useful for the work described in this derby-user email thread:
http://apache-database.10148.n7.nabble.com/Using-ASTParser-and-TreeWalker-for-parsing-SQL-query-td131219.html#a131629
Touches the following files:
------------------
M java/engine/org/apache/derby/iapi/sql/compile/CompilerContext.java
M java/engine/org/apache/derby/impl/sql/compile/CompilerContextImpl.java
Introduces scope tracking.
------------------
A java/engine/org/apache/derby/iapi/sql/compile/ScopeFilter.java
M java/engine/org/apache/derby/impl/sql/compile/SelectNode.java
Introduces scope filtering and uses it to mark the boundaries of WHERE clauses.
------------------
M java/engine/org/apache/derby/impl/sql/compile/DeleteNode.java
Uses scopes to restrict privilege checks to WHERE clauses.
------------------
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/GrantRevokeDDLTest.java
Regression tests for DELETE privileges.
> Incorrect privileges may be required for INSERT and DELETE statements.
> ----------------------------------------------------------------------
>
> Key: DERBY-6434
> URL: https://issues.apache.org/jira/browse/DERBY-6434
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.11.0.0
> Reporter: Rick Hillegas
> Labels: backport_reject_10_10
> Attachments: derby-6434-01-aa-correctInsertPrivs.diff,
> derby-6434-01-ac-correctInsertPrivs.diff,
> derby-6434-02-ac-correctDeletePrivs.diff
>
>
> This issue is a place to address problems with INSERT and DELETE statements
> similar to the problems affecting UPDATE statements recorded on DERBY-6429.
> In particular, DERBY-6432 and DERBY-6433 list some of the problems with
> INSERT statements.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
