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 Manjula G Kutty <ma...@gmail.com> on 2006/03/16 00:16:52 UTC
Question about Grant/Revoke
Hi ,
I was investigating the Grant/Revoke functionality added till now. And
found
ij> connect 'jdbc:derby:grantdb;create=true' user 'mkutty';
ij> create table t1 (i int, j int);
0 rows inserted/updated/deleted
ij> grant select on t1 to mkutty;
ERROR 42Z60: GRANT not allowed unless database property
derby.database.defaultConnectionMode has value 'sqlStandard'.
I know as per Derby docs the 'derby.database.defaultConnectionMode'
property specifies the default access permission and can have values
like "noAccess", "readOnlyAccess", or "fullAccess". So I think the above
error message is misleading.
I'm using the following derby jars
[C:\pantry\derby.jar] 10.2.0.0 alpha - (384095)
[C:\pantry\derbytools.jar] 10.2.0.0 alpha - (384095)
Also to mention that if I'm not mistaken I have to put the
derby.database.sqlAuthorization property only for upgrading derby from
version10.1 right? I came to this conclusion because I found the
follwing sentences on the functional spec under "*derby upgrade and
migration*"
http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
<quote>
When a database is created, if derby.database.sqlAuthorization property
value is true, the database gets created with standard security mode,
enabling grant and revoke. This property could be set either as a system
property in derby.properties file or as application property.
</quote>
But the following lines caught my attention
<quote>
It may be good to switch the default connection mode to standard model
and hence support grant/revoke by default in future releases.
</quote>
Is this being implemented?
Can any one please clarify?
Thanks
Manjula
Re: Question about Grant/Revoke
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Oystein Grovlen - Sun Norway wrote:
>
> I am not quite sure you understood what I meant. I do not suggest
> that we should make SQL authorization default. What I was thinking of
> was turning it on automatically when someone attempt to use it. If
> one is only running existing applications one should not be affected
> since they will not use GRANT/REVOKE. My itch is to make it easy to
> start using Derby for people that based on experiences with other
> database systems will assume that GRANT/REVOKE is available without
> having configure the system.
>
I actually proposed doing this on the list on Jan 16... See this link:
http://www.nabble.com/Re%3A-Grant-and-Revoke%2C-Part-I-...-DERBY-464...-p2410538.html
As Francois pointed out, once you make the switch to sqlAuthorization
mode, your "legacy" applications that are currently running could hit
problems. There are sufficient number of differences between legacy and
sqlAuthorization modes that, I contend, your applications would be
affected. For example, in Derby Authorization mode, most users
("fullAccess" users) are like DBAs. They can access any database object
without any explicit grant statements. The moment you switch the mode to
sqlAuthorization, most users would become regular users without access
to other objects. Someone has to issue grant statements to enable access
to objects of other users. Wouldn't many currently running applications
break after automatic switch? Note authorization is set a database level
for all users and applications of that database.
There are other differences between Derby Authorization model and SQL
standard authorization mode too... Like triggers run as INVOKER in the
former and as DEFINER in the later.. I will update functional spec to
list differences between two authorization models.
Since we both agree this can not be done for 10.2, may be we could
revisit this issue after 10.2.
Satheesh
Re: Question about Grant/Revoke
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Daniel John Debrunner wrote:
> Oystein Grovlen - Sun Norway wrote:
>
>> I was thinking of exisiting applications running against existing
>> databases vs new applications on a new database; not both existing and
>> new application against the same database. In other words, would it be
>> possible to turn it on automatically for new databases while new
>> versions against old databases will work as before?
>
> What about existing applications creating databases?
Good question which would be applicable to any application running in
soft-upgrade mode. One would have to use an old version to create
databases. If this is a problem, it must be a problem with soft-upgrade
today.
> What about new applications running against existing databases?
GRANT/REVOKE would not be available to them, and I do not anyone is
suggesting that.
>> I just realized that what I ask for is soft upgrade. In other words, do
>> we have to keep the old authorization as the default to provide for
>> backward compatibility? Could we not just require that old applications
>> run in soft upgrade mode if they do not want to deal with SQL
>> authorization?
>
> I don't think so. What if an existing application wants to use
> performance improvements in the new release, or be slightly modified to
> use JDBC 4.0 or updateable result sets?
I would think both performance improvements and updateable result sets
would be available in soft-upgrade mode. Some new features may not be
available but if they already rewriting their applications, I do not
think it should be much extra work to setup SQL authorization to mimic
the legacy mode.
--
?ystein Gr?vlen, Senior Staff Engineer
Sun Microsystems, Database Technology Group
Trondheim, Norway
Re: Question about Grant/Revoke
Posted by Daniel John Debrunner <dj...@apache.org>.
Oystein Grovlen - Sun Norway wrote:
> I was thinking of exisiting applications running against existing
> databases vs new applications on a new database; not both existing and
> new application against the same database. In other words, would it be
> possible to turn it on automatically for new databases while new
> versions against old databases will work as before?
What about existing applications creating databases?
What about new applications running against existing databases?
> I just realized that what I ask for is soft upgrade. In other words, do
> we have to keep the old authorization as the default to provide for
> backward compatibility? Could we not just require that old applications
> run in soft upgrade mode if they do not want to deal with SQL
> authorization?
I don't think so. What if an existing application wants to use
performance improvements in the new release, or be slightly modified to
use JDBC 4.0 or updateable result sets?
Dan.
Re: Question about Grant/Revoke
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Francois Orsini wrote:
> Grant or Revoke statement would have to succeed to enable sqlStandard
> authorization mode automatically, with someone having enough privilege
> to issue a successful Grant/Revoke operation in the first place - at
> the same time, implictly and silently setting the authorization mode
> to be sqlAuthorization the first time a Grant OP is invoked could be a
> problem if the user issuing it is not the/a derby system administrator
> type of role (unless he/she does it on his/her own objects) and
> ending-up turning on sqlAuthorization mode. Some admin may not want to
> see this happen.
I recognize that everybody should not be allowed to turn on SQL
authorization. I guess since the old system does not have an
administrator role this will be difficult to achieve.
> Am not understanding the following "If one is only
> running existing applications one should not be affected since they
> will not use GRANT/REVOKE" - are you suggesting an authorization mode
> at the connection/session level? It is set at the database level so
> you should not have mixed users authorizing with legacy versus others
> using sqlAuthorization...I may have misunderstood what you meant...
I was thinking of exisiting applications running against existing
databases vs new applications on a new database; not both existing and
new application against the same database. In other words, would it be
possible to turn it on automatically for new databases while new
versions against old databases will work as before?
I just realized that what I ask for is soft upgrade. In other words, do
we have to keep the old authorization as the default to provide for
backward compatibility? Could we not just require that old applications
run in soft upgrade mode if they do not want to deal with SQL authorization?
--
Øystein Grøvlen, Senior Staff Engineer
Sun Microsystems, Database Technology Group
Trondheim, Norway
Re: Question about Grant/Revoke
Posted by Francois Orsini <fr...@gmail.com>.
On 3/20/06, Oystein Grovlen - Sun Norway <Oy...@sun.com> wrote:
> Satheesh Bandaram wrote:
> >
> > Oystein Grovlen - Sun Norway wrote:
> >
> >> Satheesh Bandaram wrote:
> >>
> >> At some time in the future when GRANT/REVOKE support is more complete,
> >> would it be possible to have some way to turn on SQL authorization
> >> automatically when GRANT/REVOKE is used for the first time? I think
> >> that could improve ease of use without breaking backward compatibility.
> >
> > Derby could, but it would break backward compatibility... Currently all
> > users with 'fullAccess' mode (for defaultConnectionMode) can read/write
> > to any table in any schema. Switching to SQL authorization would mean
> > they would only be able to access their objects by default, so many
> > applications would see a break in functionality. Users have to change
> > their applications anyway, to explicitly grant privileges, so why not
> > make them set 'sqlAuthorization' flag also?
> >
>
> I am not quite sure you understood what I meant. I do not suggest that
> we should make SQL authorization default. What I was thinking of was
> turning it on automatically when someone attempt to use it. If one is
> only running existing applications one should not be affected since they
> will not use GRANT/REVOKE. My itch is to make it easy to start using
> Derby for people that based on experiences with other database systems
> will assume that GRANT/REVOKE is available without having configure the
> system.
>
Grant or Revoke statement would have to succeed to enable sqlStandard
authorization mode automatically, with someone having enough privilege
to issue a successful Grant/Revoke operation in the first place - at
the same time, implictly and silently setting the authorization mode
to be sqlAuthorization the first time a Grant OP is invoked could be a
problem if the user issuing it is not the/a derby system administrator
type of role (unless he/she does it on his/her own objects) and
ending-up turning on sqlAuthorization mode. Some admin may not want to
see this happen. Am not understanding the following "If one is only
running existing applications one should not be affected since they
will not use GRANT/REVOKE" - are you suggesting an authorization mode
at the connection/session level? It is set at the database level so
you should not have mixed users authorizing with legacy versus others
using sqlAuthorization...I may have misunderstood what you meant...
Actually, an important aspect of Cloudscape/Derby has been to make it
easy for developers to use the database and not having to worry about
issuing grant/revoke statements early in the learning cycle (as an
example and this is the same for authentication) - Maybe a way to
address your itch/issue (if not already done) could be to print a
Warning message to the user to inform him/her that he/she should
contact the database administrator (if a different person) to
enable/switch to sqlStandard mode - just a thought.
--francois
Re: Question about Grant/Revoke
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Satheesh Bandaram wrote:
>
> Oystein Grovlen - Sun Norway wrote:
>
>> Satheesh Bandaram wrote:
>>
>> At some time in the future when GRANT/REVOKE support is more complete,
>> would it be possible to have some way to turn on SQL authorization
>> automatically when GRANT/REVOKE is used for the first time? I think
>> that could improve ease of use without breaking backward compatibility.
>
> Derby could, but it would break backward compatibility... Currently all
> users with 'fullAccess' mode (for defaultConnectionMode) can read/write
> to any table in any schema. Switching to SQL authorization would mean
> they would only be able to access their objects by default, so many
> applications would see a break in functionality. Users have to change
> their applications anyway, to explicitly grant privileges, so why not
> make them set 'sqlAuthorization' flag also?
>
I am not quite sure you understood what I meant. I do not suggest that
we should make SQL authorization default. What I was thinking of was
turning it on automatically when someone attempt to use it. If one is
only running existing applications one should not be affected since they
will not use GRANT/REVOKE. My itch is to make it easy to start using
Derby for people that based on experiences with other database systems
will assume that GRANT/REVOKE is available without having configure the
system.
--
Øystein Grøvlen, Senior Staff Engineer
Sun Microsystems, Database Technology Group
Trondheim, Norway
Re: Question about Grant/Revoke
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Oystein Grovlen - Sun Norway wrote:
> Satheesh Bandaram wrote:
>
> At some time in the future when GRANT/REVOKE support is more complete,
> would it be possible to have some way to turn on SQL authorization
> automatically when GRANT/REVOKE is used for the first time? I think
> that could improve ease of use without breaking backward compatibility.
Derby could, but it would break backward compatibility... Currently all
users with 'fullAccess' mode (for defaultConnectionMode) can read/write
to any table in any schema. Switching to SQL authorization would mean
they would only be able to access their objects by default, so many
applications would see a break in functionality. Users have to change
their applications anyway, to explicitly grant privileges, so why not
make them set 'sqlAuthorization' flag also?
There are many differences in functionality between legacy authorization
model (should this be referred to as 'Derby Authorization' in docs?) to
SQL standard authorization model. (Is 'SQL Standard Authorization' or
'Standard Authorization' correct term for docs?) These differences will
force applications to change anyway, so not sure if we gain much by
automatically switching modes. Better to make it explicit, I think.
> I am not suggesting we do this for 10.2 since I think the limitations
> enforced to be able to guarantee backward compatibility for future
> releases, will probably lead to more confusions that the lack of
> GRANT/REVOKE.
>
I agree... Even if we didn't have these limitations, the authorization
model differences are enough to require marking them explicitly, in my
opinion.
Satheesh
Re: Question about Grant/Revoke
Posted by Oystein Grovlen - Sun Norway <Oy...@Sun.COM>.
Satheesh Bandaram wrote:
> No... Default authorization model in Derby 10.2 is still legacy mode..
> So if you create a database without setting sqlAuthorization property,
> you shouldn't be able to do GRANT/REVOKE. Only if you have the property
> set to true, SQL authorization would be enforced. This is to maintain
> backwards compatibility.
At some time in the future when GRANT/REVOKE support is more complete,
would it be possible to have some way to turn on SQL authorization
automatically when GRANT/REVOKE is used for the first time? I think
that could improve ease of use without breaking backward compatibility.
I am not suggesting we do this for 10.2 since I think the limitations
enforced to be able to guarantee backward compatibility for future
releases, will probably lead to more confusions that the lack of
GRANT/REVOKE.
--
Øystein
Re: Question about Grant/Revoke
Posted by Mamta Satoor <ms...@gmail.com>.
Actually, Manjula, looks like Satheesh made a checkin this morning which has
changed the property Dderby.database.defaultConnectionMode=sqlStandard to
derby.database.sqlAuthorization. It should be set to true to enabled
grant/revoke. So, if you do a sync on Derby 10.2 code and recompile, the
property you are using should work fine and should let you use grant/revoke.
Mamta
On 3/18/06, Mamta Satoor <ms...@gmail.com> wrote:
>
> Manjula, following is how I start ij to enable grant/revoke
> $ java -Dderby.database.defaultConnectionMode=sqlStandard -
> Dij.exceptionTrace=true org.apache.derby.tools.ij
>
> So, the property you need in derby.properties file is
> Dderby.database.defaultConnectionMode=sqlStandard. I haven't done sync on
> my client in quite some time but I think it is still the right property to
> enable grant/revoke.
>
> Mamta
>
>
> On 3/17/06, Manjula G Kutty <manjula.kutty@gmail.com > wrote:
> >
> > So if I put derby.database.sqlAuthorization=true in the derby.properties
> > file then the command like this should execute without error message?
> > ij> connect 'jdbc:derby:grntdb;create=true' user 'mkutty';
> > ij> create table tab1(i int, j int);
> > 0 rows inserted/updated/deleted
> > ij> grant select on tab1 to mkutty;
> >
> > But after the last statement I 'm getting the error message :
> > ERROR 42Z60: GRANT not allowed unless database property
> > derby.database.defaultCo
> > nnectionMode has value 'sqlStandard'.
> >
> >
> > Am I doing something wrong here?
> >
> > --Manjula
> >
> > Rajesh Kartha wrote:
> >
> > > >
> > > >So that means if I put the 'derby.database.sqlAutherization' property
> > > in the derby.property file can I do grant/Revoke now?
> > > >
> > > As I understand, currently the statements should execute, but it won't
> >
> > > be enforced till Part 2 for DERBY-464 is applied. So any
> > > negative tests to verify permissions will not work.
> > >
> > > -Rajesh
> > >
> > >
> > > On 3/15/06, *Manjula G Kutty* < manjula.kutty@gmail.com
> > > <ma...@gmail.com>> wrote:
> > >
> > > Hi Satheesh,
> > > Thanks for your reply. So that means if I put the
> > > 'derby.database.sqlAutherization' property in the derby.propertyfile
> > > can I do grant/Revoke now? Also one minor suggestion from my view,
> > The
> > > functional spec talks about these property under the heading
> > 'derby
> > > upgrade and migration'. Can you move that under some other
> > meaningful
> > > heading?
> > >
> > >
> > > Thanks
> > > Manjula
> > >
> > >
> > > Satheesh Bandaram wrote:
> > >
> > > >Manjula G Kutty wrote:
> > > >
> > > >
> > > >
> > > >>Hi ,
> > > >>I was investigating the Grant/Revoke functionality added till
> > > now. And
> > > >>found
> > > >>
> > > >>0 rows inserted/updated/deleted
> > > >>ij> grant select on t1 to mkutty;
> > > >>ERROR 42Z60: GRANT not allowed unless database property
> > > >> derby.database.defaultConnectionMode has value 'sqlStandard'.
> > > >>
> > > >>
> > > >
> > > >This was the original proposal on how to ask for SQL
> > authorization
> > > >mode... by setting defaultConnectionMode. Following further
> > > discussion
> > > >on the list, the functional spec has been changed say
> > > >'derby.database.sqlAuthorization' is the way to ask for SQL
> > > >authorization. Change in functionality hasn't been reflected in
> > > the code
> > > >yet.
> > > >
> > > >
> > > >
> > > >>Also to mention that if I'm not mistaken I have to put the
> > > >>derby.database.sqlAuthorization property only for upgrading
> > > derby from
> > > >>version10.1 right? I came to this conclusion because I found
> > the
> > > >>follwing sentences on the functional spec under "*derby upgrade
> > and
> > > >>migration*"
> > > >>
> > > >>
> > > >
> > > >No... Default authorization model in Derby 10.2 is still legacy
> > > mode..
> > > >So if you create a database without setting sqlAuthorization
> > > property,
> > > >you shouldn't be able to do GRANT/REVOKE. Only if you have the
> > > property
> > > >set to true, SQL authorization would be enforced. This is to
> > > maintain
> > > >backwards compatibility.
> > > >
> > > >Satheesh
> > > >
> > > >
> > > >
> > > >>
> > >
> > http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
> > > <http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
> > >
> > > >>
> > > >>
> > > >><quote>
> > > >>When a database is created, if derby.database.sqlAuthorization
> > > >>property value is true, the database gets created with standard
> > > >>security mode, enabling grant and revoke. This property could be
> > > set
> > > >>either as a system property in derby.properties file or as
> > > application
> > > >>property.
> > > >></quote>
> > > >>
> > > >>But the following lines caught my attention
> > > >>
> > > >><quote>
> > > >>It may be good to switch the default connection mode to standard
> >
> > > model
> > > >>and hence support grant/revoke by default in future releases.
> > > >></quote>
> > > >>
> > > >>Is this being implemented?
> > > >>
> > > >>Can any one please clarify?
> > > >>
> > > >>Thanks
> > > >>Manjula
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
Re: Question about Grant/Revoke
Posted by Mamta Satoor <ms...@gmail.com>.
Manjula, following is how I start ij to enable grant/revoke
$ java -Dderby.database.defaultConnectionMode=sqlStandard -
Dij.exceptionTrace=true org.apache.derby.tools.ij
So, the property you need in derby.properties file is
Dderby.database.defaultConnectionMode=sqlStandard. I haven't done sync on my
client in quite some time but I think it is still the right property to
enable grant/revoke.
Mamta
On 3/17/06, Manjula G Kutty <ma...@gmail.com> wrote:
>
> So if I put derby.database.sqlAuthorization=true in the derby.properties
> file then the command like this should execute without error message?
> ij> connect 'jdbc:derby:grntdb;create=true' user 'mkutty';
> ij> create table tab1(i int, j int);
> 0 rows inserted/updated/deleted
> ij> grant select on tab1 to mkutty;
>
> But after the last statement I 'm getting the error message :
> ERROR 42Z60: GRANT not allowed unless database property
> derby.database.defaultCo
> nnectionMode has value 'sqlStandard'.
>
>
> Am I doing something wrong here?
>
> --Manjula
>
> Rajesh Kartha wrote:
>
> > >
> > >So that means if I put the 'derby.database.sqlAutherization' property
> > in the derby.property file can I do grant/Revoke now?
> > >
> > As I understand, currently the statements should execute, but it won't
> > be enforced till Part 2 for DERBY-464 is applied. So any
> > negative tests to verify permissions will not work.
> >
> > -Rajesh
> >
> >
> > On 3/15/06, *Manjula G Kutty* < manjula.kutty@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Hi Satheesh,
> > Thanks for your reply. So that means if I put the
> > 'derby.database.sqlAutherization' property in the derby.propertyfile
> > can I do grant/Revoke now? Also one minor suggestion from my view,
> The
> > functional spec talks about these property under the heading 'derby
> > upgrade and migration'. Can you move that under some other
> meaningful
> > heading?
> >
> >
> > Thanks
> > Manjula
> >
> >
> > Satheesh Bandaram wrote:
> >
> > >Manjula G Kutty wrote:
> > >
> > >
> > >
> > >>Hi ,
> > >>I was investigating the Grant/Revoke functionality added till
> > now. And
> > >>found
> > >>
> > >>0 rows inserted/updated/deleted
> > >>ij> grant select on t1 to mkutty;
> > >>ERROR 42Z60: GRANT not allowed unless database property
> > >>derby.database.defaultConnectionMode has value 'sqlStandard'.
> > >>
> > >>
> > >
> > >This was the original proposal on how to ask for SQL authorization
> > >mode... by setting defaultConnectionMode. Following further
> > discussion
> > >on the list, the functional spec has been changed say
> > >'derby.database.sqlAuthorization' is the way to ask for SQL
> > >authorization. Change in functionality hasn't been reflected in
> > the code
> > >yet.
> > >
> > >
> > >
> > >>Also to mention that if I'm not mistaken I have to put the
> > >>derby.database.sqlAuthorization property only for upgrading
> > derby from
> > >>version10.1 right? I came to this conclusion because I found the
> > >>follwing sentences on the functional spec under "*derby upgrade
> and
> > >>migration*"
> > >>
> > >>
> > >
> > >No... Default authorization model in Derby 10.2 is still legacy
> > mode..
> > >So if you create a database without setting sqlAuthorization
> > property,
> > >you shouldn't be able to do GRANT/REVOKE. Only if you have the
> > property
> > >set to true, SQL authorization would be enforced. This is to
> > maintain
> > >backwards compatibility.
> > >
> > >Satheesh
> > >
> > >
> > >
> > >>
> >
> http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
> > <
> http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
> >
> > >>
> > >>
> > >><quote>
> > >>When a database is created, if derby.database.sqlAuthorization
> > >>property value is true, the database gets created with standard
> > >>security mode, enabling grant and revoke. This property could be
> > set
> > >>either as a system property in derby.properties file or as
> > application
> > >>property.
> > >></quote>
> > >>
> > >>But the following lines caught my attention
> > >>
> > >><quote>
> > >>It may be good to switch the default connection mode to standard
> > model
> > >>and hence support grant/revoke by default in future releases.
> > >></quote>
> > >>
> > >>Is this being implemented?
> > >>
> > >>Can any one please clarify?
> > >>
> > >>Thanks
> > >>Manjula
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >
> > >
> >
> >
>
>
Re: Question about Grant/Revoke
Posted by Manjula G Kutty <ma...@gmail.com>.
So if I put derby.database.sqlAuthorization=true in the derby.properties
file then the command like this should execute without error message?
ij> connect 'jdbc:derby:grntdb;create=true' user 'mkutty';
ij> create table tab1(i int, j int);
0 rows inserted/updated/deleted
ij> grant select on tab1 to mkutty;
But after the last statement I 'm getting the error message :
ERROR 42Z60: GRANT not allowed unless database property
derby.database.defaultCo
nnectionMode has value 'sqlStandard'.
Am I doing something wrong here?
--Manjula
Rajesh Kartha wrote:
> >
> >So that means if I put the 'derby.database.sqlAutherization' property
> in the derby.property file can I do grant/Revoke now?
> >
> As I understand, currently the statements should execute, but it won't
> be enforced till Part 2 for DERBY-464 is applied. So any
> negative tests to verify permissions will not work.
>
> -Rajesh
>
>
> On 3/15/06, *Manjula G Kutty* < manjula.kutty@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hi Satheesh,
> Thanks for your reply. So that means if I put the
> 'derby.database.sqlAutherization' property in the derby.property file
> can I do grant/Revoke now? Also one minor suggestion from my view, The
> functional spec talks about these property under the heading 'derby
> upgrade and migration'. Can you move that under some other meaningful
> heading?
>
>
> Thanks
> Manjula
>
>
> Satheesh Bandaram wrote:
>
> >Manjula G Kutty wrote:
> >
> >
> >
> >>Hi ,
> >>I was investigating the Grant/Revoke functionality added till
> now. And
> >>found
> >>
> >>0 rows inserted/updated/deleted
> >>ij> grant select on t1 to mkutty;
> >>ERROR 42Z60: GRANT not allowed unless database property
> >>derby.database.defaultConnectionMode has value 'sqlStandard'.
> >>
> >>
> >
> >This was the original proposal on how to ask for SQL authorization
> >mode... by setting defaultConnectionMode. Following further
> discussion
> >on the list, the functional spec has been changed say
> >'derby.database.sqlAuthorization' is the way to ask for SQL
> >authorization. Change in functionality hasn't been reflected in
> the code
> >yet.
> >
> >
> >
> >>Also to mention that if I'm not mistaken I have to put the
> >>derby.database.sqlAuthorization property only for upgrading
> derby from
> >>version10.1 right? I came to this conclusion because I found the
> >>follwing sentences on the functional spec under "*derby upgrade and
> >>migration*"
> >>
> >>
> >
> >No... Default authorization model in Derby 10.2 is still legacy
> mode..
> >So if you create a database without setting sqlAuthorization
> property,
> >you shouldn't be able to do GRANT/REVOKE. Only if you have the
> property
> >set to true, SQL authorization would be enforced. This is to
> maintain
> >backwards compatibility.
> >
> >Satheesh
> >
> >
> >
> >>
> http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
> <http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html>
> >>
> >>
> >><quote>
> >>When a database is created, if derby.database.sqlAuthorization
> >>property value is true, the database gets created with standard
> >>security mode, enabling grant and revoke. This property could be
> set
> >>either as a system property in derby.properties file or as
> application
> >>property.
> >></quote>
> >>
> >>But the following lines caught my attention
> >>
> >><quote>
> >>It may be good to switch the default connection mode to standard
> model
> >>and hence support grant/revoke by default in future releases.
> >></quote>
> >>
> >>Is this being implemented?
> >>
> >>Can any one please clarify?
> >>
> >>Thanks
> >>Manjula
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
Re: Question about Grant/Revoke
Posted by Rajesh Kartha <ka...@gmail.com>.
>
>So that means if I put the 'derby.database.sqlAutherization' property in
the derby.property file can I do grant/Revoke now?
>
As I understand, currently the statements should execute, but it won't be
enforced till Part 2 for DERBY-464 is applied. So any
negative tests to verify permissions will not work.
-Rajesh
On 3/15/06, Manjula G Kutty < manjula.kutty@gmail.com> wrote:
>
> Hi Satheesh,
> Thanks for your reply. So that means if I put the
> 'derby.database.sqlAutherization' property in the derby.property file
> can I do grant/Revoke now? Also one minor suggestion from my view, The
> functional spec talks about these property under the heading 'derby
> upgrade and migration'. Can you move that under some other meaningful
> heading?
>
>
> Thanks
> Manjula
>
>
> Satheesh Bandaram wrote:
>
> >Manjula G Kutty wrote:
> >
> >
> >
> >>Hi ,
> >>I was investigating the Grant/Revoke functionality added till now. And
> >>found
> >>
> >>0 rows inserted/updated/deleted
> >>ij> grant select on t1 to mkutty;
> >>ERROR 42Z60: GRANT not allowed unless database property
> >>derby.database.defaultConnectionMode has value 'sqlStandard'.
> >>
> >>
> >
> >This was the original proposal on how to ask for SQL authorization
> >mode... by setting defaultConnectionMode. Following further discussion
> >on the list, the functional spec has been changed say
> >'derby.database.sqlAuthorization' is the way to ask for SQL
> >authorization. Change in functionality hasn't been reflected in the code
> >yet.
> >
> >
> >
> >>Also to mention that if I'm not mistaken I have to put the
> >>derby.database.sqlAuthorization property only for upgrading derby from
> >>version10.1 right? I came to this conclusion because I found the
> >>follwing sentences on the functional spec under "*derby upgrade and
> >>migration*"
> >>
> >>
> >
> >No... Default authorization model in Derby 10.2 is still legacy mode..
> >So if you create a database without setting sqlAuthorization property,
> >you shouldn't be able to do GRANT/REVOKE. Only if you have the property
> >set to true, SQL authorization would be enforced. This is to maintain
> >backwards compatibility.
> >
> >Satheesh
> >
> >
> >
> >>http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
>
> >>
> >>
> >><quote>
> >>When a database is created, if derby.database.sqlAuthorization
> >>property value is true, the database gets created with standard
> >>security mode, enabling grant and revoke. This property could be set
> >>either as a system property in derby.properties file or as application
> >>property.
> >></quote>
> >>
> >>But the following lines caught my attention
> >>
> >><quote>
> >>It may be good to switch the default connection mode to standard model
> >>and hence support grant/revoke by default in future releases.
> >></quote>
> >>
> >>Is this being implemented?
> >>
> >>Can any one please clarify?
> >>
> >>Thanks
> >>Manjula
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >
>
>
Re: Question about Grant/Revoke
Posted by Manjula G Kutty <ma...@gmail.com>.
Hi Satheesh,
Thanks for your reply. So that means if I put the
'derby.database.sqlAutherization' property in the derby.property file
can I do grant/Revoke now? Also one minor suggestion from my view, The
functional spec talks about these property under the heading 'derby
upgrade and migration'. Can you move that under some other meaningful
heading?
Thanks
Manjula
Satheesh Bandaram wrote:
>Manjula G Kutty wrote:
>
>
>
>>Hi ,
>>I was investigating the Grant/Revoke functionality added till now. And
>>found
>>
>>0 rows inserted/updated/deleted
>>ij> grant select on t1 to mkutty;
>>ERROR 42Z60: GRANT not allowed unless database property
>>derby.database.defaultConnectionMode has value 'sqlStandard'.
>>
>>
>
>This was the original proposal on how to ask for SQL authorization
>mode... by setting defaultConnectionMode. Following further discussion
>on the list, the functional spec has been changed say
>'derby.database.sqlAuthorization' is the way to ask for SQL
>authorization. Change in functionality hasn't been reflected in the code
>yet.
>
>
>
>>Also to mention that if I'm not mistaken I have to put the
>>derby.database.sqlAuthorization property only for upgrading derby from
>>version10.1 right? I came to this conclusion because I found the
>>follwing sentences on the functional spec under "*derby upgrade and
>>migration*"
>>
>>
>
>No... Default authorization model in Derby 10.2 is still legacy mode..
>So if you create a database without setting sqlAuthorization property,
>you shouldn't be able to do GRANT/REVOKE. Only if you have the property
>set to true, SQL authorization would be enforced. This is to maintain
>backwards compatibility.
>
>Satheesh
>
>
>
>>http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
>>
>>
>><quote>
>>When a database is created, if derby.database.sqlAuthorization
>>property value is true, the database gets created with standard
>>security mode, enabling grant and revoke. This property could be set
>>either as a system property in derby.properties file or as application
>>property.
>></quote>
>>
>>But the following lines caught my attention
>>
>><quote>
>>It may be good to switch the default connection mode to standard model
>>and hence support grant/revoke by default in future releases.
>></quote>
>>
>>Is this being implemented?
>>
>>Can any one please clarify?
>>
>>Thanks
>>Manjula
>>
>>
>>
>>
>>
>>
>
>
>
>
Re: Question about Grant/Revoke
Posted by Satheesh Bandaram <sa...@Sourcery.Org>.
Manjula G Kutty wrote:
> Hi ,
> I was investigating the Grant/Revoke functionality added till now. And
> found
>
> 0 rows inserted/updated/deleted
> ij> grant select on t1 to mkutty;
> ERROR 42Z60: GRANT not allowed unless database property
> derby.database.defaultConnectionMode has value 'sqlStandard'.
This was the original proposal on how to ask for SQL authorization
mode... by setting defaultConnectionMode. Following further discussion
on the list, the functional spec has been changed say
'derby.database.sqlAuthorization' is the way to ask for SQL
authorization. Change in functionality hasn't been reflected in the code
yet.
> Also to mention that if I'm not mistaken I have to put the
> derby.database.sqlAuthorization property only for upgrading derby from
> version10.1 right? I came to this conclusion because I found the
> follwing sentences on the functional spec under "*derby upgrade and
> migration*"
No... Default authorization model in Derby 10.2 is still legacy mode..
So if you create a database without setting sqlAuthorization property,
you shouldn't be able to do GRANT/REVOKE. Only if you have the property
set to true, SQL authorization would be enforced. This is to maintain
backwards compatibility.
Satheesh
>
> http://issues.apache.org/jira/secure/attachment/12324061/grantRevokeSpec_v2.html
>
>
> <quote>
> When a database is created, if derby.database.sqlAuthorization
> property value is true, the database gets created with standard
> security mode, enabling grant and revoke. This property could be set
> either as a system property in derby.properties file or as application
> property.
> </quote>
>
> But the following lines caught my attention
>
> <quote>
> It may be good to switch the default connection mode to standard model
> and hence support grant/revoke by default in future releases.
> </quote>
>
> Is this being implemented?
>
> Can any one please clarify?
>
> Thanks
> Manjula
>
>
>
>