db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: SYSTEMALIAS flag in SYSALIASES table
Date Thu, 09 Mar 2006 04:53:50 GMT
Mamta Satoor wrote:

> 
> SQL standards have the default EXTERNAL SECURITY as DEFINER and the
> upgrade code changes in RoutineAliasInfo will mark the pre-10.2
> databases with EXTERNAL SECURITY of DEFINER for the existing routines.
> But that is not what we want for system routines (as per the
> Grant/Revoke spec). The system routines should run with the permissions
> of INVOKER and not DEFINER and hence above assumption, in
> RoutineAliasInfo.readExeternal, of marking all pre-10.2 routines with
> EXECUTE SECURITY of INVOKER is incorrect.
>  
> To get around this problem, I was thinking that during hard upgrade of
> pre-10.2 db, I should drop the system routines in
> DD_Version.doFullUpgrade and recreate them with EXTERNAL SECURITY of
> INVOKER. In order to determine what routines in SYSALIASES belong to
> system routines, I was going to check the systemalias boolean column but
> looks like I can't rely on it. I am thinking I can use SCHEMAID in
> SYSALIASES to determine if a routine is a system routine and if so, then
> drop that routine and recreate it with EXTERNAL SECURITY of INVOKER.
> This will take care of system routines. As for pre-10.2 user defined
> routines, they will get marked with EXTERNAL SECURITY of OWNER when
> RoutineAliasInfo.readExternal gets called on them.


What's the effect of the EXTERNAL SECURITY INVOKER/OWNER flag when the
sql standard grant/revoke mode is not enabled?

Will the EXTERNAL SECURITY INVOKER/OWNER clauses be accepted on the
CREATE FUNCTION/PROCEDURE when the sql standard grant/revoke mode is not
enabled?

Dan.


Mime
View raw message