Re: Grant and Revoke, Part I ... DERBY-464...

On 1/16/06, Satheesh Bandaram <[EMAIL PROTECTED]> wrote: Francois Orsini wrote: Yes and I will be posting more details very soon. Great... Would love to see more details. If we are proposing combining both authorization models, why not go the whole way and say Gr

Re: Grant and Revoke, Part I ... DERBY-464...

Francois Orsini wrote: Yes and I will be posting more details very soon. Great... Would love to see more details. If we are proposing combining both authorization models, why not go the whole way and say Grant/Revoke is always enabled in a 10.2 database? If applications

Re: Grant and Revoke, Part I ... DERBY-464...

The idea and goal is not to affect existing applications if they upgrade to 10.2. Others can correct me if this is not the case.On 1/16/06, Kathey Marsden <[EMAIL PROTECTED]> wrote: Satheesh Bandaram wrote:>If we are proposing combining both authorization models, why not go the whole>way and say G

Re: Grant and Revoke, Part I ... DERBY-464...

Comments inlined.On 1/16/06, Satheesh Bandaram <[EMAIL PROTECTED]> wrote: Daniel John Debrunner wrote: Satheesh Bandaram wrote I think mixing both will lead to confusion to users many alreadyfamiliar with the ansi subset model being proposed. This will alsocreate hurdles as we

Re: Grant and Revoke, Part I ... DERBY-464...

Satheesh Bandaram wrote: >If we are proposing combining both authorization models, why not go the whole >way and say Grant/Revoke is always enabled in a 10.2 database? If applications >want to keep their current authorization model, they don't need to use new >fine-grained access control allow

Re: Grant and Revoke, Part I ... DERBY-464...

Daniel John Debrunner wrote: Satheesh Bandaram wrote I think mixing both will lead to confusion to users many already familiar with the ansi subset model being proposed. This will also create hurdles as we expand authorization scheme to support roles and "system privileges" as Franco

Re: Grant and Revoke, Part I ... DERBY-464...

Satheesh Bandaram wrote: > Daniel John Debrunner wrote: > > >>I wonder if we should look at grant/revoke augmenting the existing >>authorization model instead of replacing it. > Why would we want to augment the new authorization model with the old > one? Is there something that old model provid

Re: Grant and Revoke, Part I ... DERBY-464...

Francois Orsini wrote: > Comments inlined: > > On 1/10/06, *Daniel John Debrunner* <[EMAIL PROTECTED] > > wrote: > > > I wonder if we should look at grant/revoke augmenting the existing > authorization model instead of replacing it. > > > Well, it is not compl

Re: Grant and Revoke, Part I ... DERBY-464...

Daniel John Debrunner wrote: >I wonder if we should look at grant/revoke augmenting the existing >authorization model instead of replacing it. > > > Why would we want to augment the new authorization model with the old one? Is there something that old model provides that new model doesn't have?

Re: Grant and Revoke, Part I ... DERBY-464...

Comments inlined:On 1/10/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: I wonder if we should look at grant/revoke augmenting the existingauthorization model instead of replacing it. Well, it is not completely replaced since legacy would still be supported (until sqlStandard is set explicitly

Re: Grant and Revoke, Part I ... DERBY-464...

I wonder if we should look at grant/revoke augmenting the existing authorization model instead of replacing it. The existing authorization functionality has: - disallow a user - allow a user read-only - allow a user full-access Grant/revoke does not replace this functionality, it could be

Re: Grant and Revoke, Part I ... DERBY-464...

I originally picked the name 'secureMode' to cover not just grant & revoke work I am doing, but also expecting more enhancements in the security area. I know Francois is working on something related for sure.. But may be the name should reflect what is actually being done, to avoid misleading.

Re: Grant and Revoke, Part I ... DERBY-464...

I did not pick 'ansiAuthMode' because one could easily confuse 'Auth' for Authentication instead of Authorization (these are 2 different beasts) - hence why I leaned towards 'ansiAuthoMode' ;)On 1/10/06, David W. Van Couvering <[EMAIL PROTECTED] > wrote:ansiAuthMode (not AuthoMode) sounds good to m

Re: Grant and Revoke, Part I ... DERBY-464...

Daniel John Debrunner wrote: I'm still thinking about this 'secureMode' approach and the interaction with the existing authentication model. One issue I do have is the name of the attribute, 'secureMode'. I don't believe that the current grant/revoke syntax makes Derby completely secure, thus t

Re: Grant and Revoke, Part I ... DERBY-464...

ansiAuthMode (not AuthoMode) sounds good to me, I agree that there is a false sense of security around the term secureMode. How secure is secure? And this is just about authentication and authorization, necessary but not necessarily sufficient in terms of security. David Francois Orsini wro

Re: Grant and Revoke, Part I ... DERBY-464...

Agreed - I have had the same reserve but could not really come up with a better name ;) Although I was thinking of 'ansiAuthorizationMode' (for ANSI authorization mode) or 'ansiAuthoMode'On 1/10/06, Daniel John Debrunner < [EMAIL PROTECTED]> wrote:I'm still thinking about this 'secureMode' approac

Re: Grant and Revoke, Part I ... DERBY-464...

Francois Orsini wrote: > 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

Re: Grant and Revoke, Part I ... DERBY-464...

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 r

Re: Grant and Revoke, Part I ... DERBY-464...

We could use 'defaultConnectionMode' property to store secureMode like you said, but .. 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

Re: Grant and Revoke, Part I ... DERBY-464...

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. --francoisOn 1/6/06, Satheesh Bandaram <[EMAIL PROTECTED]> w

Re: Grant and Revoke, Part I ... DERBY-464...

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 u

Re: Grant and Revoke, Part I ... DERBY-464...

Hi Francois, Francois Orsini wrote: Hi Satheesh, Regarding the issues you mentioned:   > 1) Should Derby support upgrading a 10.1 database to 10.2 directly into 'sqlStandard' mode (optionally) or not? I would say no - as this is a new feature of 10.2, we should let the user configure

Re: Grant and Revoke, Part I ... DERBY-464...

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. My current proposal (attached to Jira) would allow migrating databases from legacy security mode into sqlStandard mode, but not the

Re: Grant and Revoke, Part I ... DERBY-464...

Right - at least you get a choice...On 12/22/05, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: Francois Orsini wrote:>>3) Dan raised an important question about whether > defaultConnectionMode should be made a database-only property>   > and without affecting existing applications. I am curr

Re: Grant and Revoke, Part I ... DERBY-464...

Francois Orsini wrote: >>3) Dan raised an important question about whether > defaultConnectionMode should be made a database-only property > > and without affecting existing applications. I am currently thinking > if defaultConnectionMode is set to sqlStandard \ > > as a database property

Re: Grant and Revoke, Part I ... DERBY-464...

Hi Satheesh, Regarding the issues you mentioned:   > 1) Should Derby support upgrading a 10.1 database to 10.2 directly into 'sqlStandard' mode (optionally) or not? I would say no - as this is a new feature of 10.2, we should let the user configure it on its own after upgrade. Also what does it

Re: [Fwd: Grant and Revoke, Part I ... DERBY-464...]

heesh Subject: Grant and Revoke, Part I ... DERBY-464... From: Satheesh Bandaram <[EMAIL PROTECTED]> Date: Fri, 02 Dec 2005 11:03:00 -0800 To: derby-dev@db

[Fwd: Grant and Revoke, Part I ... DERBY-464...]

I just attached Grant and Revoke, Part I patch to Jira entry. (DERBY-464) This implements following items I listed in the previous message. Some notes on the implementation so far: dblook needs to be enhanced to emit DDL for grant statements. I am working on a JUnit based test suite with

Grant and Revoke, Part I ... DERBY-464...

I would like to start contributing code that implements Grant/Revoke in batches. My first patch would include DDL support for both Grant/Revoke. This patch has passed 'derbyALL' suite and contains implementation for the following. Let me know if anyone would like to join completing the rest. Lo