[jira] Issue Comment Edited: (DERBY-3223) SQL roles: make use of privileges granted to roles in actual privilege checking

["Dag H. Wanvik (JIRA)" <ji...@apache.org>]

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

dagw edited comment on DERBY-3223 at 8/26/08 10:49 AM:
----------------------------------------------------------------

Uploading a new patch, derby-3223-invalidate-activations-1 for review;
regressions ran ok.

This patch changes the way we handle what happens in the following
situation:

A session has a current role set. A prepared statement has been
executed which relies on the current role to get the necessary
privileges. Then, if the current role changes, we need to re-check if
sufficient privileges are still in place.

Currently, this is being handled by invalidating the compiled plan of
the prepared statement, causing all activations of the prepared
statement to be discarded. The checking happens the first time the
prepared statement is used in a session, i.e. when the activation is
constructed. So, invalidated the compiled plans (shared across
sessions) is a sufficient, but heavy-handed way of forcing a re-check
in the session which changed its current role.

This patch does away with this, instead marking the activation as
invalid when the current role changes. So, the next time execution of
the prepared statement is attempted, the activation is recreated for
the session context. This is quicker for the current session than
recompiling the execution plan, and also shields other sessions from
having to recreate their activation.

Any open result sets will remain usable as before, since these remain
open; even though the old (base)activation is no longer referenced
from the GenericActivationHolder, there is a reference to the old
activation from the result set, so it stays alive.

It is only the next execute of the prepared statement after a SET ROLE
that we will notice if privileges are now insufficient. This is the
same behavior as before (and the same behavior as other privilege
revokes).

I have tried to check that this new method is safe, but please don't
assume anything. It should be thread safe, since only the current
session's thread is involved.

Since this is just an optimization, the role tests are unmodified.


      was (Author: dagw):
    Uploading a new patch, derby-3223-invalidate-activations-1 for review;
regressions ran ok.

This patch changes the way we handle what happens in the following
situation:

A session has a current role set. A prepared statement has been
executed which relies on the current role to get the necessary
privileges. Then, if the current role changes, we need to re-check if
sufficient privileges are still in place.

Currently, this is being handled by invalidating the compiled plan of
the prepared statement, causing all activations of the prepared
statement to be discarded. The checking happens the first time the
prepared statement is used in a session, i.e. when the activation is
constructed. So, invalidated the compiled plans (shared across
sessions) is a sufficient, but heavy-handed way of forcing a re-check
in the session which changed its current role.

This patch does away with this, instead marking the activation as
invalid when the current role changes. So, the next time execution of
the prepared statement is attempted, the activation is recreated for
the session context. This is quicker for the current session that
recompiling the execution plan, and also shields other sessions from
having to recreate their activation.

Any open result sets will remain usable as before, since these remain
open; even though the old (base)activation is no longer referenced
from the GenericActivationHolder, there is a reference to the old
activation from the result set, so it stays alive.

It is only the next execute of the prepared statement after a SET ROLE
that we will notice if privileges are now insufficient. This is the
same behavior as before (and the same behavior as other privilege
revokes).

I have tried to check that this new method is safe, but please don't
assume anything. It should be thread safe, since only the current
session's thread is involved.

Since this is just an optimization, the role tests are unmodified.

  
> SQL roles: make use of privileges granted to roles in actual privilege checking
> -------------------------------------------------------------------------------
>
>                 Key: DERBY-3223
>                 URL: https://issues.apache.org/jira/browse/DERBY-3223
>             Project: Derby
>          Issue Type: Task
>          Components: Security, SQL
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>             Fix For: 10.5.0.0
>
>         Attachments: derby-3223-1a.diff, derby-3223-1a.stat, derby-3223-1b.diff, derby-3223-1b.stat, derby-3223-1c.diff, derby-3223-1c.stat, derby-3223-1d.diff, derby-3223-1d.stat, derby-3223-activate-roles-1.diff, derby-3223-activate-roles-1.stat, derby-3223-activate-roles-2.diff, derby-3223-activate-roles-2.stat, derby-3223-activate-roles-2b.diff, derby-3223-activate-roles-2b.stat, derby-3223-invalidate-activations-1.diff, derby-3223-invalidate-activations-1.stat, derby-3223-revise-iterator-api-b.diff, derby-3223-revise-iterator-api-b.stat, derby-3223-revise-iterator-api.diff, derby-3223-revise-iterator-api.stat, derby-3223-revocation-logic-1.diff, derby-3223-revocation-logic-1.stat, derby-3223-revocation-logic-2.diff, derby-3223-revocation-logic-2.stat, derby-3223-revocation-logic-2.txt, derby-3223-revocation-logic-3.diff, derby-3223-revocation-logic-3.stat, derby-3223-revocation-logic-4.diff, derby-3223-revocation-logic-4.stat, derby-3223-revocation-logic-5.diff, derby-3223-revocation-logic-5.stat, roles.sql, roles2.sql, roles3.sql
>
>
> Pushing out to 10.5

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