db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: Grant/Revoke subtask - EXTERNAL SECURITY DEFINER | EXTERNAL SECURITY INVOKER
Date Fri, 24 Feb 2006 21:30:07 GMT
Actually, thinking more about it, I think there should be checks for
specific numbers, ie 0 for pre-10.2, 1 for 10.2, 2 for some future release
which requires more fields in AliasInfo and so on and so forth. That way, we
can keep using the same "unused value" to indiciate different versions of on
disk AliasInfo formats.

 if (readMoreFromDisk == 0) //means pre-10.2
if (readMoreFromDisk == 1) //means 10.2
In future
if (readMoreFromDisk == 2) //future release X that changes the AliasInfo
structure
 if (readMoreFromDisk == 3) //future release X+n that changes the AliasInfo
structure

Mamta


On 2/24/06, Satheesh Bandaram <satheesh@sourcery.org> wrote:
>
> Sounds right!... Minor comment, may be this should be changed:
>
> if (readMoreFromDisk == 1)
>
> to
>
> if (readMoreFromDisk *> 0*)
>
> to support future versions. This approach does seem easier and "cleaner"
> in this context.
>
> Satheesh
>
> Mamta Satoor wrote:
>
> Actually, I think I figured it out.
>
> A pre-10.2 db, in it's on disk AliasInfo format, will have an unused value
> which is set to 0.
>
> 10.2 release Derby will check if the on disk AliasInfo's unused value is
> set to 0(which means it is dealing with pre-10.2 db) and if yes, then it
> will default the external security info to true meaning use invoker's
> privileges.
>
> A 10.2 db's on disk AliasInfo will have the unused value set to 1. This
> will be an indication that we are dealing with a 10.2 database and we
> should go ahead and read the external security information from the disk
> which could be true/false.
>
> Here is how I think the changed readExternal and writeExternal should look
> like in 10.2 catalog.types.RoutineAliasInfo
>
>  public void readExternal( ObjectInput in )
>    throws IOException, ClassNotFoundException
>  {
>   super.readExternal(in);
>   specificName = (String) in.readObject();
>   dynamicResultSets = in.readInt();
>   parameterCount = in.readInt();
>   parameterStyle = in.readShort();
>   sqlAllowed = in.readShort();
>   returnType = (TypeDescriptor) in.readObject();
>   calledOnNullInput = in.readBoolean();
>   int readMoreFromDisk = in.readInt(); //This will be 0 from pre-10.2 db
>
>   if (parameterCount != 0) {
>    parameterNames = new String[parameterCount];
>    parameterTypes = new TypeDescriptor[parameterCount];
>
>    ArrayUtil.readArrayItems(in, parameterNames);
>    ArrayUtil.readArrayItems(in, parameterTypes);
>    parameterModes = ArrayUtil.readIntArray(in);
>
>   } else {
>    parameterNames = null;
>    parameterTypes = null;
>    parameterModes = null;
>   }
>
>   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
>    executeUsingPermissionsOfRoutineInvoker = true;
>
>   in.readInt(); //future expansion for post 10.2 release
>
>  }
>
>  /**
>   * Write this object to a stream of stored objects.
>   *
>   * @param out write bytes here.
>   *
>   * @exception IOException  thrown on error
>   */
>  public void writeExternal( ObjectOutput out )
>    throws IOException
>  {
>   super.writeExternal(out);
>   out.writeObject(specificName);
>   out.writeInt(dynamicResultSets);
>   out.writeInt(parameterCount);
>   out.writeShort(parameterStyle);
>   out.writeShort (sqlAllowed);
>   out.writeObject(returnType);
>   out.writeBoolean(calledOnNullInput);
>   out.writeInt(1); // 1 means we are dealing with 10.2 on disk format
>   if (parameterCount != 0) {
>    ArrayUtil.writeArrayItems (out, parameterNames);
>    ArrayUtil.writeArrayItems(out, parameterTypes);
>    ArrayUtil.writeIntArray(out, parameterModes);
>   }
>   out.writeBoolean(executeUsingPermissionsOfRoutineInvoker);
>   out.writeInt(0); //future expansion for post 10.2 releases
>  }
>
>
>
> On 2/24/06, Mamta Satoor <msatoor@gmail.com> wrote:
> >
> > Hi,
> >
> > Dan, could you expand a little more on
> > "The RoutineAliasInfo has the correct structure to support expansion. It
> > writes out an unused value, set at 0. This could be bumped to indicate
> > that more data needs to be read, e.g. 1 means the external security info
> >
> > flag is written to disk etc. etc"?
> >
> > What I am looking for is what happens during upgrade if I add another
> > field to RoutineAliasInfo(since this change will become part of SYSALIASES
> > AliasInfo field)? I am not sure if it is as easy as just changing the
> > RoutineAliasInfo class and everything will work fine, especially during an
> > upgrade.
> >
> > Also, looking at Derby-337 (dblook doesn't generate SQL statements for
> > SQL functions.), it seems like Army had encountered some problems when he
> > had to add a filed to RoutineAliasInfo.
> >
> > Any thoughts on this will be helpful,
> > Mamta
> >
> >
> >  On 2/22/06, Daniel John Debrunner <djd@apache.org > wrote:
> > >
> > > Satheesh Bandaram wrote:
> > >
> > > >
> > > > Mamta Satoor wrote:
> > > >
> > > >> 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)?
> > > >
> > > > Here are some of my concerns about adding another field to
> > > > RoutineAliasInfo.
> > > >
> > > >    1. It would become harder to extract this info from
> > > RoutineAliasInfo
> > > >       as it is a Java object for any metadata processing... like in
> > > >       dblook or for other GUI tools. We would have to document how
> > > >       RoutineAliasInfo gets generated as a character type and
> > > maintain
> > > >       that format in the future.
> > > >    2. Have to support existing RoutineAliasInfo instances created in
> > > >       existing databases. You would have to introduce a new
> > > >       RoutineAliasInfo version or add a new mapping to another java
> > > object.
> > >
> > > The RoutineAliasInfo has the correct structure to support expansion.
> > > It
> > > writes out an unused value, set at 0. This could be bumped to indicate
> > >
> > > that more data needs to be read, e.g. 1 means the external security
> > > info
> > > flag is written to disk etc. etc.
> > >
> > > Dan.
> > >
> > >
> > >
> >
>

Mime
View raw message