You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Francois Orsini <fr...@gmail.com> on 2006/01/07 00:59:34 UTC
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.
--francois
On 1/6/06, Satheesh Bandaram <sa...@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.
>
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Francois Orsini <fr...@gmail.com>.
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 <Da...@sun.com> wrote:
>
> 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 wrote:
> > 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* < djd@apache.org
> > <ma...@apache.org>> 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 this
> attribute
> > may mislead people. Note sure I have a better name though. :-(
> >
> > Dan.
> >
> >
>
>
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
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 wrote:
> 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* < djd@apache.org
> <ma...@apache.org>> 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 this attribute
> may mislead people. Note sure I have a better name though. :-(
>
> Dan.
>
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Francois Orsini <fr...@gmail.com>.
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 <dj...@apache.org> 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 this attribute
> may mislead people. Note sure I have a better name though. :-(
>
> Dan.
>
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by John Embretsen <Jo...@sun.com>.
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 this attribute
> may mislead people. Note sure I have a better name though. :-(
>
> Dan.
I agree, a property/attribute called "secureMode" will most likely
become quite misleading in the long run, as there are other dimensions
to derby security than just GRANT/REVOKE.
I have not followed this discussion closely, but unless the property
values have to be "true" / "false", I propose something like this:
Property/attribute name: "sqlAuth" (or "sqlAuthorization", just
"authorization", or similar).
Legal values: "sqlStandard", "derbyLegacy" (or whatever you see fit).
--
John
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Francois Orsini <fr...@gmail.com>.
On 1/16/06, Satheesh Bandaram <sa...@sourcery.org> 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 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 allowed by grant/revoke. This
> > preserves legacy model for them.
>
>
> If Grant/Revoke is always enabled but there is no metadata (including
> legacy one), then I believe a user would not have access by default to
> anything except his/her own schema (objects). By default, when no legacy
> permissions are set, the default access for a database is full (read-write)
> access, which would be different for Grant/Revoke whereas explicit
> privileges have to be granted for a user to access a table that is not
> his/her - Again we're dealing with different semantics across modes which
> IMHO should not be mixed.
>
> This is a good point. Applications would see differences so probably not
> OK. I was trying to combine both authorization models without having to
> worry about when to switch the model and to remove ambiguities.
>
>
> 10.2 databases could use grant/revoke to get more control over access to
> > their objects. Hopefully Derby will also have system privileges and roles to
> > complete this model at some point. This proposal removes the need to have
> > another property, like 'derby.database.sqlAuthorization'. One advantage
> > I see with this is that we don't need to handle the case of someone issuing
> > Grant/Revoke with sqlAuthorization set to false and trying to find
> > appropriate time to switch the authorization scheme.
>
>
> This case/scenario would indeed be very good for users to prepare and
> switch to sqlAuthorization when all the metadata is there - meaning they
> would have issued all the required Grant/Revoke statements to satisfy what
> they had with the legacy mode (*assuming* there is support for Roles and
> System privileges which is something I'm working on) - it is a nice way for
> people to migrate from legacy to grant/revoke IMO.
>
> This matches what Dan proposed as "option A", right?
Yes it does.
Once issue I see is how to handle EXTERNAL SECURITY clause in this combined
> > authorization model. Current legacy databases have EXTERNAL SECURITY set to
> > INVOKER, where as my proposal calls for changing this to DEFINER. This could
> > be seen as changing the behavior of Derby without sufficient warning. We
> > could address this by one of the following:
> >
> > 1. Automatically moving existing routines to INVOKER security mode
> > during database upgrade to 10.2 and making all new routine
> > creation mandating specifying this security clause. (No default) Would help
> > users to consider one or the other model. We could add a default for this
> > clause to DEFINER (as specified by ANSI) later.
> > 2. Move existing routines to INVOKER during upgrade and by
> > switching default behavior to DEFINER with sufficient warning messages to
> > release notes and by raising SQL warning if a default mode of DEFINER is
> > picked.
> > 3. Any other suggestions?
> >
> > My suggestion would be not to mix 2 different authorization modes
> unless we absolutely have to, if it does not impact performance and does not
> add too much complexity to the runtime permission checking logic.
>
> As a first phase for Roles and System privileges support (which are
> independent), am working on implementing what is required at a minimum to
> support what's there in legacy to be available with Grant/Revoke as well as
> adding critical and minimal System privileges that have to be supported in
> Derby.
>
> Sounds nice... Would love to see more details. Would this satisfy Dan's
> concerns?
Yes it would indeed.
Satheesh
>
> It would be good to drive to a decision soon. I am making progress on
> > second part of Grant/Revoke, implementing the permission scheme enforcement.
> >
> > Satheesh
>
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Francois Orsini <fr...@gmail.com>.
Comments inlined.
On 1/16/06, Satheesh Bandaram <sa...@sourcery.org> wrote:
>
>
> 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 Francois calls them and other security capabilities.
>
> I'm more proposing this to deal with existing Derby applications and
> finding an easy way to bring them into the new world of grant revoke.
>
> You do raise good points, as usual. I see your argument for ease of
> migration as the most compelling reason to avoid two different security
> models. Since Francois said he is working on adding system privileges and/or
> roles, hopefully your other concerns would be met at some point.
Yes and I will be posting more details very soon.
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 allowed by grant/revoke. This
> preserves legacy model for them.
Combining both modes sounds interesting as long as it does not impact
runtime performance by much (since permission checks would have to be done
in the 2 realms) and it seems to me that runtime permission checking would
get more complicated which we should try to avoid as it is in the main
compilation/execution path - permission resolution check would be more
complicated IMO - I understand the motivation for bringing them to
Grant/Revoke mode but it can also be confusing for users to mix both modes (
i.e. different semantics and syntax being mixed) - If Grant/Revoke is always
enabled but there is no metadata (including legacy one), then I believe a
user would not have access by default to anything except his/her own schema
(objects). By default, when no legacy permissions are set, the default
access for a database is full (read-write) access, which would be different
for Grant/Revoke whereas explicit privileges have to be granted for a user
to access a table that is not his/her - Again we're dealing with different
semantics across modes which IMHO should not be mixed.
10.2 databases could use grant/revoke to get more control over access to
> their objects. Hopefully Derby will also have system privileges and roles to
> complete this model at some point. This proposal removes the need to have
> another property, like 'derby.database.sqlAuthorization'. One advantage I
> see with this is that we don't need to handle the case of someone issuing
> Grant/Revoke with sqlAuthorization set to false and trying to find
> appropriate time to switch the authorization scheme.
This case/scenario would indeed be very good for users to prepare and switch
to sqlAuthorization when all the metadata is there - meaning they would have
issued all the required Grant/Revoke statements to satisfy what they had
with the legacy mode (*assuming* there is support for Roles and System
privileges which is something I'm working on) - it is a nice way for people
to migrate from legacy to grant/revoke IMO.
Once issue I see is how to handle EXTERNAL SECURITY clause in this combined
> authorization model. Current legacy databases have EXTERNAL SECURITY set to
> INVOKER, where as my proposal calls for changing this to DEFINER. This could
> be seen as changing the behavior of Derby without sufficient warning. We
> could address this by one of the following:
>
> 1. Automatically moving existing routines to INVOKER security mode
> during database upgrade to 10.2 and making all new routine creation
> mandating specifying this security clause. (No default) Would help users to
> consider one or the other model. We could add a default for this clause to
> DEFINER (as specified by ANSI) later.
> 2. Move existing routines to INVOKER during upgrade and by switching
> default behavior to DEFINER with sufficient warning messages to release
> notes and by raising SQL warning if a default mode of DEFINER is picked.
> 3. Any other suggestions?
>
> My suggestion would be not to mix 2 different authorization modes unless
we absolutely have to, if it does not impact performance and does not add
too much complexity to the runtime permission checking logic.
As a first phase for Roles and System privileges support (which are
independent), am working on implementing what is required at a minimum to
support what's there in legacy to be available with Grant/Revoke as well as
adding critical and minimal System privileges that have to be supported in
Derby.
It would be good to drive to a decision soon. I am making progress on
> second part of Grant/Revoke, implementing the permission scheme enforcement.
>
> Satheesh
>
> Users familiar with the ansi subset model would just use that, no need
> to get involved with the defaultConnectionModel. Though until roles and
> system privileges is supported, they might need to to ensure a secure
> system. I haven't seen any proposal on these roles or system privileges
> so I'm looking at how secure Derby will be in its next release given
> what has been proposed and is being worked on. If we have a release
> about 6 months from the last one, it will be around March. I think
> someone was going to set up a wiki page with what "10.3" would include,
> though that hasn't happened yet.
>
> Dan.
>
>
>
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Daniel John Debrunner <dj...@apache.org>.
Francois Orsini wrote:
> Comments inlined:
>
> On 1/10/06, *Daniel John Debrunner* <djd@apache.org
> <ma...@apache.org>> wrote:
>
>
> I wonder if we should look at grant/revoke augmenting the existing
> authorization model instead of replacing it.
>
>
> Well, it is not completely replaced since legacy would still be
> supported (until sqlStandard is set explicitly)
Yes, the code is still there, but the proposed model is the application
chooses existing mode or grant revoke. Thus if grant revoke is used the
existing authorization is replaced.
Dan.
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Francois Orsini <fr...@gmail.com>.
Comments inlined:
On 1/10/06, Daniel John Debrunner <dj...@apache.org> wrote:
>
>
> I wonder if we should look at grant/revoke augmenting the existing
> authorization model instead of replacing it.
Well, it is not completely replaced since legacy would still be supported
(until sqlStandard is set explicitly)
The existing authorization functionality has:
>
> - disallow a user
> - allow a user read-only
> - allow a user full-access
- Disallow a user to access a database or system can be done via a REVOKE
CONNECT statement - it is not part of Satheesh's charter but this is
something am looking at as focusing more on System privileges.
- User read-only can be set via a 'read-only' role (known practice).
- User full-access can be set via a 'full-access' role (again this is where
ROLE(s) shine)
Grant/revoke does not replace this functionality, it could be seen as
> adding fine-grain control to the read only or read-write access.
>
> Then it seems to come down to how does an application selects the old
> model of coarse grain control versus fine grain (grant/revoke).
>
> One way is a property like
>
> derby.database.sqlAuthorization={true|false}
> (derby.language.sqlAuthorization ??)
>
> I would like to be able to set a property in derby.properties that made
> the default mode for new databases to be grant/revoke.
Sounds good..
I think the JDBC attribute (secureMode) is possibly a security risk, if
> upgrade to grant/revoke mode is allowed, it seems to allow any remote
> user to make that change. Which could allow a denial of service attack
> on existing applications. It may be that such an attack could also be
> made through setting a database property, but I don't think that's a
> justification for adding a new (potential) hole.
Unless it is restricted to the database owner - but I agree this is an
issue. I mean without Grant & Revoke *enabled*, there would not be much
system privilege check - kinda being able to shutdown a database or the
whole system as of today.
Another issue is the potential number of security related properties and
> ensuring they are set correctly. If
> derby.database.sqlAuthorization=false and a GRANT statement was
> executed, then it seems there are three choices:
>
> A - allow the GRANT to succeed, but it is not enforced (since
> derby.database.sqlAuthorization=false)
At least a warning should be issued to the user as this last one might not
have realized that the property had not been set (looking at the other way
around) - still the metadata would be updated.
B - throw an exception (warning?) on execution indicating
> derby.database.sqlAuthorization=false and thus grant statements are not
> applicable
This could be restrictive - We could allow users to set-up grant & revoke
privileges and then turning on the sqlStandard authorization mode at a later
stage. Of course there could be some issues against existing and running
queries but this has to be verified based on the current grant&revoke
design.
C - Change the database to grant/revoke mode
I don't think that an automatic change of authorization mode would be very
welcome by users. Especially if the database is running with users against
it.
Maybe B would be the case for a user that was not the database owner
> (creator) and C would only be allowed by the database creator.
>
> Also similar exceptions or warnings are probably needed if grant/revoke
> is enabled but no authentication is set up.
Warnings would be good...
Dan.
>
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Francois Orsini <fr...@gmail.com>.
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 <km...@sbcglobal.net> wrote:
>
> 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 allowed by grant/revoke. This preserves
> legacy
> >model for them.
> >
> >
> I have not followed this thread at all as I thought it was all
> pertaining to new functionality. Are there changes being proposed that
> might affect existing applications if they upgrade to 10.2?
>
> Thanks
>
> Kathey
>
>
Re: Grant and Revoke, Part II ... DERBY-464...
Posted by Francois Orsini <fr...@gmail.com>.
Hi Satheesh,
Please find my comments enclosed below:
On 2/8/06, Satheesh Bandaram <sa...@sourcery.org> wrote:
[...]
>
> I am not sure if previous discussion about migrating a legacy mode database
> to Grant Revoke model was finalized. It seems there were two thoughts:
>
>
> 1. Keep authorization models separate. Legacy mode database can be migrated to
> sqlStandard model by connecting with a URL property. (sqlAuthorization=true)
How to restrict anyone to specify this new URL property? This is a
system privilege by itself that would need to be granted unless it is
a user with an 'ADMIN' role (which we don't have yet). Are we also
going to allow users to move from legacy to grant/revoke during the
database upgrade phase? I thought so.
> 2. Dan proposed combining both models with Grant and Revoke capability being
> seen as adding fine-grain access control on top of current model. While this
> proposal doesn't impact Grant and Revoke work being done currently by much,
> it may have implications on some future work. (like system privileges) This
> does make it easier for existing databases to adapt new capabilities.
I remember we discussed this - This sounds good if Ansi ROLES are not
there but when they are, then equivalent roles for the various legacy
authorization modes can be defined to act the same way. For instance,
a role for a 'read-only' authorization identifier (i.e. user/role) can
be defined to act the same as legacy
'derby.database.readOnlyAccessUsers', etc - you just assign some
defined 'READ_ONLY' role to the users that you reference as part of
the derby.database.readOnlyAccessUsers' derby property...Hence, no
need to mix 2 authorization modes of different standards but until
ROLES are there I agree with Dan this is a *must* to have...
> Satheesh
>
> 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 Francois calls them and other security capabilities.
>
> I'm more proposing this to deal with existing Derby applications and
> finding an easy way to bring them into the new world of grant revoke.
> Users familiar with the ansi subset model would just use that, no need
> to get involved with the defaultConnectionModel. Though until roles and
> system privileges is supported, they might need to to ensure a secure
> system. I haven't seen any proposal on these roles or system privileges
> so I'm looking at how secure Derby will be in its next release given
> what has been proposed and is being worked on.
>
> Dan.
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Kathey Marsden <km...@sbcglobal.net>.
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 allowed by grant/revoke. This preserves legacy
>model for them.
>
>
I have not followed this thread at all as I thought it was all
pertaining to new functionality. Are there changes being proposed that
might affect existing applications if they upgrade to 10.2?
Thanks
Kathey
Re: Grant and Revoke, Part II ... DERBY-464...
Posted by Daniel John Debrunner <dj...@apache.org>.
Satheesh Bandaram wrote:
> I am not sure if previous discussion about migrating a legacy mode
> database to Grant Revoke model was finalized. It seems there were two
> thoughts:
>
> 1. Keep authorization models separate. Legacy mode database can be
> migrated to sqlStandard model by connecting with a URL property.
> (sqlAuthorization=true)
> 2. Dan proposed combining both models with Grant and Revoke
> capability being seen as adding fine-grain access control on top
> of current model. While this proposal doesn't impact Grant and
> Revoke work being done currently by much, it may have implications
> on some future work. (like system privileges) This does make it
> easier for existing databases to adapt new capabilities.
I guess I don't understand how 1) is useful. In this mode by adding
grant/revoke in its current form you are removing key authorization
options. For example if I'm using an LDAP authentication scheme I won't
be able to limt the set of authenticated LDAP users who can connect to
my database. I can do that now, and with 2) I can do that and have more
fine grained authorization.
Dan.
Re: Grant and Revoke, Part II ... DERBY-464...
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
Thanks, Satheesh. FYI, Francois is in France for a family emergency,
so you may not hear from him.
David
Satheesh Bandaram wrote:
> I am getting ready to submit a patch for review, that adds parts of
> Grant and Revoke Part II support. With this patch, I am trying to
> enforce table privileges that are granted to users using Part I patch
> that is already submitted. After this patch, I will work on adding
> upgrade support to upgrade a 10.1 database to 10.2, JDBC metadata
> changes and migration model for legacy database to enable grant and
> revoke functionality. Once all these changes are done, I will then try
> to address other parts of the spec, like routine privileges, views and
> triggers. Let me know if there are any concerns or comments on this plan.
>
> I am not sure if previous discussion about migrating a legacy mode
> database to Grant Revoke model was finalized. It seems there were two
> thoughts:
>
> 1. Keep authorization models separate. Legacy mode database can be
> migrated to sqlStandard model by connecting with a URL property.
> (sqlAuthorization=true)
> 2. Dan proposed combining both models with Grant and Revoke
> capability being seen as adding fine-grain access control on top
> of current model. While this proposal doesn't impact Grant and
> Revoke work being done currently by much, it may have implications
> on some future work. (like system privileges) This does make it
> easier for existing databases to adapt new capabilities.
>
> Satheesh
>
> 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 Francois calls them and other security capabilities.
>>>
>>>
>>
>>I'm more proposing this to deal with existing Derby applications and
>>finding an easy way to bring them into the new world of grant revoke.
>>Users familiar with the ansi subset model would just use that, no need
>>to get involved with the defaultConnectionModel. Though until roles and
>>system privileges is supported, they might need to to ensure a secure
>>system. I haven't seen any proposal on these roles or system privileges
>>so I'm looking at how secure Derby will be in its next release given
>>what has been proposed and is being worked on.
>>
>>Dan.
>>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Daniel John Debrunner <dj...@apache.org>.
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 provides that new model doesn't
> have?
Yes, the ability to deny a user access to the database and the ability
to make a user's connection read-only. Your current grant/revoke work is
really an extension to the current authorization, it does not replace
the existing functionality.
Note that the property controlling the existing authorization is
'defaultConnectionMode', supporting grant/revoke is not a *connection*
mode, it is a state of the database.
> 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 Francois calls them and other security capabilities.
I'm more proposing this to deal with existing Derby applications and
finding an easy way to bring them into the new world of grant revoke.
Users familiar with the ansi subset model would just use that, no need
to get involved with the defaultConnectionModel. Though until roles and
system privileges is supported, they might need to to ensure a secure
system. I haven't seen any proposal on these roles or system privileges
so I'm looking at how secure Derby will be in its next release given
what has been proposed and is being worked on. If we have a release
about 6 months from the last one, it will be around March. I think
someone was going to set up a wiki page with what "10.3" would include,
though that hasn't happened yet.
Dan.
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
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? 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 Francois calls them and other security capabilities.
>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 seen as
>adding fine-grain control to the read only or read-write access.
>
>
The new model does allow this access, with fine-grain control. How would
we handle the case of a read-only user having INSERT privilege? Guess we
could make read-only access override INSERT privilege.
>Then it seems to come down to how does an application selects the old
>model of coarse grain control versus fine grain (grant/revoke).
>
>One way is a property like
>
>derby.database.sqlAuthorization={true|false}
>(derby.language.sqlAuthorization ??)
>
>I would like to be able to set a property in derby.properties that made
>the default mode for new databases to be grant/revoke.
>
>I think the JDBC attribute (secureMode) is possibly a security risk, if
>upgrade to grant/revoke mode is allowed, it seems to allow any remote
>user to make that change. Which could allow a denial of service attack
>on existing applications. It may be that such an attack could also be
>made through setting a database property, but I don't think that's a
>justification for adding a new (potential) hole.
>
>
I think we already have a security hole like this... Remote users can
upgrade a database for you when the Sysadm intent may have been to use
the database in soft upgrade mode. This kind of security holes are best
plugged by adding support for roles or system privileges to have Sysadm
privilege. Francois may be working on something in this area...
>Another issue is the potential number of security related properties and
>ensuring they are set correctly. If
>
>
You are proposing to add another one! The list below can be pretty
confusing if not deceiving to new or beginner users to Derby.
Satheesh
>derby.database.sqlAuthorization=false and a GRANT statement was
>executed, then it seems there are three choices:
>
> A - allow the GRANT to succeed, but it is not enforced (since
>derby.database.sqlAuthorization=false)
>
> B - throw an exception (warning?) on execution indicating
>derby.database.sqlAuthorization=false and thus grant statements are not
>applicable
>
> C - Change the database to grant/revoke mode
>
>
>Maybe B would be the case for a user that was not the database owner
>(creator) and C would only be allowed by the database creator.
>
>Also similar exceptions or warnings are probably needed if grant/revoke
>is enabled but no authentication is set up.
>
>
>Dan.
>
>
>
>
>
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Daniel John Debrunner <dj...@apache.org>.
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 seen as
adding fine-grain control to the read only or read-write access.
Then it seems to come down to how does an application selects the old
model of coarse grain control versus fine grain (grant/revoke).
One way is a property like
derby.database.sqlAuthorization={true|false}
(derby.language.sqlAuthorization ??)
I would like to be able to set a property in derby.properties that made
the default mode for new databases to be grant/revoke.
I think the JDBC attribute (secureMode) is possibly a security risk, if
upgrade to grant/revoke mode is allowed, it seems to allow any remote
user to make that change. Which could allow a denial of service attack
on existing applications. It may be that such an attack could also be
made through setting a database property, but I don't think that's a
justification for adding a new (potential) hole.
Another issue is the potential number of security related properties and
ensuring they are set correctly. If
derby.database.sqlAuthorization=false and a GRANT statement was
executed, then it seems there are three choices:
A - allow the GRANT to succeed, but it is not enforced (since
derby.database.sqlAuthorization=false)
B - throw an exception (warning?) on execution indicating
derby.database.sqlAuthorization=false and thus grant statements are not
applicable
C - Change the database to grant/revoke mode
Maybe B would be the case for a user that was not the database owner
(creator) and C would only be allowed by the database creator.
Also similar exceptions or warnings are probably needed if grant/revoke
is enabled but no authentication is set up.
Dan.
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Daniel John Debrunner <dj...@apache.org>.
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 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
> <ma...@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
>> <ma...@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.
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 this attribute
may mislead people. Note sure I have a better name though. :-(
Dan.
Re: Grant and Revoke, Part I ... DERBY-464...
Posted by Francois Orsini <fr...@gmail.com>.
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 <sa...@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.
> >
> >
>