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.
