Re: Grant/Revoke subtask - EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER

[Mamta Satoor]

Entered Derby-1023.

 

Satheesh, I was looking through the code last night and saw following comment, about external security info flag, in CreateAliasNode.init line 195

    // GrantRevoke TODO: Figure out how to save external security info. Putting this in
    // RoutineAliasInfo may not be the best long term solution
It seems like RoutineAliasInfo will be the logical place to keep this external security information, similar to the way we keep other information like called on null input, parameter count etc. Did you have reservations about this approach because we want to move away from using objects in the system tables (which in this case is AliasInfo in SYSALIASES table)?

 

thanks,

Mamta

 

On 2/21/06, Satheesh Bandaram <[EMAIL PROTECTED] > wrote:

Thanks for picking this up. A sub-task under DERBY-464 sounds good.

Satheesh

Mamta Satoor wrote:

> Hi,
>
> Satheesh has added the parser support for EXTERNAL SECURITY DEFINER |
> EXTERNAL SECURITY INVOKER on a routine (function or procedure). eg
> from lang/grantRevoke.sql test
> CREATE PROCEDURE AUTH_TEST.addUserUtility(IN userName VARCHAR(50), IN
> permission VARCHAR(22))
> LANGUAGE JAVA PARAMETER STYLE JAVA
> EXTERNAL SECURITY INVOKER
> EXTERNAL NAME 'org.apache.derby.database.UserUtility.add ';
>
> But this information about INVOKER vs DEFINER doesn't get stored in
> any system table. I am looking into finishing up this subtask to see
> what may be required during compile, execute and upgrade times for
> this subtask. Will send more information as I make more progress.
>
> thanks,
> Mamta
>
> ps Will it be useful to create a subtask of Derby-464 to keep track of
> this work?