db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: Grant and Revoke, Part I ... DERBY-464...
Date Tue, 10 Jan 2006 17:12:08 GMT
I think we just *cannot* let anyone override the 'defaultConnectionMode'
database configuration property - The user would have had to be granted a
'system privilege' of some sort. Now as far as migrating a secure database
to a legacy mode one, there would need to be good reasons for that, such as
running an embedded application with no need for a secure database mode. But
then if we allow migration of secure mode to legacy, might as well keep the
property scheme as you have originally defined it and no new connection url
property.

--francois

On 1/8/06, Satheesh Bandaram < satheesh@sourcery.org> wrote:
>
> We could use 'defaultConnectionMode' property to store secureMode like you
> said, but ..
>
>    1. What would happen if a user tries to set the value to
>    'fullAccess' or 'readOnlyAccess' in a secure database? Should we catch the
>    case and raise an error since otherwise the database would switch to being a
>    legacy database.
>     2. While I am not promising migration from secure database to
>    legacy database, overloading this property will make the value being lost if
>    someone adds logic to provide this migration later and if someone tries to
>    do a roundtrip of a database from legacy mode...
>
> Satheesh
>
> Francois Orsini wrote:
>
> Sounds good.
>
> Where would you persist the secureMode value?
>
> I guess it would then be ok to consider 'defaultConnectionMode' to be
> legacy only unless you are thinking of still using it to store secureMode
> value? Could you clarify please.
>
> --francois
>
> On 1/6/06, Satheesh Bandaram <satheesh@sourcery.org> wrote:
> >
> > I have been thinking if use of properties is the right way to chose
> > sqlStandard security mode or legacy mode... Properties are meant to be more
> > dynamic in nature and since I don't yet plan to allow switching between
> > SqlStandard mode (with support for Grant and Revoke) to legacy mode.
> >
> > I think use of URL property to indicate which security mode is wanted
> > during a database create time is more natural. If one wishes to create a
> > database with support for Grant and Revoke, it could be specified by a URL
> > attribute like secureMode.
> >
> > ij> connect 'jdbc:derby:securedb;create=true;*secureMode=true*';
> >
> > If secureMode is not specified, current default of legacy mode database
> > without grant/revoke capability would be created in 10.2 release. If
> > secureMode is true, a database with support for grant/revoke statements is
> > created. In this database, property value of 'defaultConnectionMode' is a
> > no-op.
> >
> > We could also use this mechanism to trigger a legacy database migration
> > to sqlStandard security mode. During booting of a legacy database with
> > secureMode=true could trigger this migration in security mode.
> >
> > Any thoughts or comments?
> >
> > Satheesh
> >
> > Satheesh Bandaram wrote:
> >
> > Let us look at the issues and some assumptions. A solution may follow
> > from it and this definitely needs some debate. The assumptions here are my
> > proposals only.
> >
> >    1. My current proposal (attached to Jira) would allow migrating
> >    databases from legacy security mode into sqlStandard mode, but not the
> >    otherway.
> >    2. It is preferred to avoid change in behavior to existing
> >    applications that may be using defaultConnectionMode.
> >    3. Current default value for defaultConnectionMode is 'fullAccess'
> >    and not going to be changed to sqlStandard for 10.2 release. I do
> >    think some feedback on how sqlStandard mode is working is needed before any
> >    changes.
> >     4. It is possible to have some databases in legacy security mode
> >    and some in sqlStandard mode in any installation.
> >    5. sqlStandard mode is likely going to be the default mode at some
> >    in the future and likely preferred if not the only mode at long time later.
> >
> > Are these the likely goals for a solution? We could use
> > derby.database.propertiesOnly to override system properties with
> > database properties, but that would change all properties, right?
> >
> > Satheesh
> >
> > Daniel John Debrunner wrote:
> >
> > I'm not sure about this, I can't find what Satheesh is refering to when
> > he said 'Dan raised an important question ...'.
> >
> > I found one comment by me in the thread where I was talking about system
> > properties in general.
> >
> >
> >
> > Databases do have an existing way to override system properties, by
> > setting the database property derby.database.propertiesOnly
> >
> >
> >
> > http://db.apache.org/derby/docs/10.1/tuning/rtunproper24390.html
> >
> > Dan.
> >
> >
>

Mime
View raw message