Mamta Satoor wrote:
Actually, I was getting ready to submit my patch for EXTERNAL
SECURITY changes but realized that my upgrade code(in
RoutineAliasInfo.readExternal) will not mark the system routines with
EXTERNAL SECURITY of INVOKER.
I am not sure if upgrade code should be changing SECURITY clause.. Even
after upgrade from 10.1 to 10.2, sqlStandard mode is not enabled
automatically, right?
<>Here is how RoutineAliasInfo.readExternal looks like with my
changes for upgrade(changes in Bold)
if (readMoreFromDisk > 1 || readMoreFromDisk < 0) {
if (SanityManager.DEBUG)
SanityManager.THROWASSERT
("Invalid value " + readMoreFromDisk + " read from the disk.");
} else if(readMoreFromDisk == 1)
//If true, that means we are dealing with 10.2 db and hence
//we should read external security info from the disk
executeUsingPermissionsOfRoutineInvoker = in.readBoolean();
else
//We are dealing with pre-10.2 db, which doesn't have external
//security feature on routines and hence no information about
//external security will be found on the disk. Hence, initialize
//external security information to definer's permissions as per
//SQL standards.
executeUsingPermissionsOfRoutineInvoker = false;
}
I think Derby should assume EXTERNAL SECURITY being INVOKER if not
explicitly specified in the RoutineAliasInfo instance. This will solve
the issue for system procedures that will have RoutineAliasInfo version
being at 0.
I am still wondering what we should do with existing routines at
database mode switching time, whether they can continue to run in
INVOKER mode or switch to DEFINER mode. Since the routines were created
for INVOKER model, that may make sense for them. But currently written
routines are likely to need application logic changes anyway in
grantRevoke mode, so may be it is ok to switch them to DEFINER model...
Any one have any suggestions here?
Your changes would become very easy if we continue to run existing
routines in INVOKER model. But if we decide to switch them to DEFINER
model, at the mode switching time, we may have to visit every
RoutineAliasInfo and set DEFINER flag on them. This means we have to
update RoutineAliasInfo instance with a new one at version 1.
Does that sound right and solve your issues?
Satheesh
thanks,
Mamta
On 3/8/06, Satheesh
Bandaram <[EMAIL PROTECTED]>
wrote:
Mamta Satoor wrote:
> Hi,
>
> I ran following query in a 10.2 db
> select alias,systemalias from sys.sysaliases;
>
I don't think systemalias column in sys.sysaliases is being used in
Derby currently. It was probably used in Cloudscape product, from which
Derby originally came from. All routines in system schemas have this
flag set to 'false'. May be documentation should say this column is
'Reserved'?
What information do you need?
Satheesh
> I was expecting to see true for systemalias column for Derby
supplied
> routines like SYSCS_COMPRESS_TABLE, SYSCS_EXPORT_TABLE etc. But all
> the rows returned by the query above have systemalias set to false.
> According to the docs on SYSALIASES table, the column systemalias
will
> be set to true for system supplief/built-in aliases. Is the doc
> incorrect, system table incorrect or I am missing something?
>
> thanks,
> Mamta
|
