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 Thu, 23 Feb 2006 19:19:31 GMT
Thinking further about database upgrade for EXTERNAL SECURITY DEFINER |
EXTERNAL SECURITY INVOKER information, I think when a pre-10.2 Derby
database is upgraded, the SYSALIASES table should initialize the new column
for external security info with "true". This "true" for external
security means that the routine should be executed with the invoker's
privileges. This will be more restrictive than granting the execute
privileges of the routine definer. Does that sound right? Once we decide on
this, the functional spec for grant/revoke should be updated with this
information.

Also, I am thinking of using "EXECUTE_USING_INVOKER_PRIVILEGES" as column
name for new column in SYSALIASES for external security info. Any other
suggestion?

thanks,
Mamta


On 2/22/06, Mamta Satoor <msatoor@gmail.com> wrote:
>
> Thanks for sharing your thoughts on this, Satheesh. I will spend more time
> on it to see if external security info can be added as another column to the
> SYSALIASES table rather than as another filed to RoutineAliasInfo.
>
> 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