db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6616) User procedures can call system procedures, circumventing SQL authorization.
Date Wed, 09 Jul 2014 16:07:07 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14056400#comment-14056400

Rick Hillegas commented on DERBY-6616:

Tests passed cleanly for me on derby-6616-01-ad-reauthorize.diff. Let me describe the approach:

1) I abstracted out the logic in GenericAuthorizer which we run when we check SQL authorization
at execution time. This is the logic which computes the closure of the privileges granted
to your current role and then checks that the closure contains all of the privileges on a
list. For the normal execution path, that list is constructed when your SQL statement is compiled.

2) I added an authorize() method to SecurityUtil which lets us check at any time whether the
current session enjoys EXECUTE privilege on a system routine. Basically, the method cooks
up a list with one EXECUTE permission on it and then calls the method which was exposed by
the work in step (1).

3) Then I peppered the engine with calls to SecurityUtil.authorize(). Many of these calls
are in SystemProcedures itself, the class which contains the public entry points for the Derby
system routines. However, it turns out that SystemProcedures often calls other public entry
points, which may call further public entry points, and so on. In those cases, I have tried
to push the call to SecurityUtil.authorize() as far down as possible.

4) However, I have avoided pushing down the call to SecurityUtil.authorize() in cases where
I thought that it might affect the performance of the main execution path. This means that
there are still unprotected public entry points on internal objects like LanguageConnectionContext,
DataDictionary, and TransactionController. I think that this exposure needs to be addressed
by a solution to DERBY-6648.

Touches the following files:


M       java/engine/org/apache/derby/iapi/sql/conn/Authorizer.java
M       java/engine/org/apache/derby/impl/sql/conn/GenericAuthorizer.java

Changes for (1).


M       java/engine/org/apache/derby/iapi/security/SecurityUtil.java
A       java/engine/org/apache/derby/iapi/security/Securable.java

Changes for (2).


M       java/engine/org/apache/derby/iapi/db/PropertyInfo.java
M       java/engine/org/apache/derby/iapi/db/ConsistencyChecker.java
M       java/engine/org/apache/derby/impl/load/Import.java
M       java/engine/org/apache/derby/impl/load/Export.java
M       java/engine/org/apache/derby/impl/sql/execute/JarUtil.java
M       java/engine/org/apache/derby/impl/store/access/RAMAccessManager.java
M       java/engine/org/apache/derby/catalog/SystemProcedures.java

Changes for (3).


M       java/testing/org/apache/derbyTesting/functionTests/tests/lang/DBOAccessTest.java


> User procedures can call system procedures, circumventing SQL authorization.
> ----------------------------------------------------------------------------
>                 Key: DERBY-6616
>                 URL: https://issues.apache.org/jira/browse/DERBY-6616
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions:
>            Reporter: Rick Hillegas
>            Assignee: Rick Hillegas
>         Attachments: SystemProcWrapper.java, derby-6616-01-ad-reauthorize.diff
> System procedures are implemented as public static methods in org.apache.derby.catalog.SystemProcedures.
These methods can be called by code in user-written procedures. This allows a user-written
procedure to circumvent the SQL authorization checks which are supposed to limit some procedures
to being called only by the DBO. I will attach a repro.

This message was sent by Atlassian JIRA

View raw message