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 Rick Hillegas <Ri...@Sun.COM> on 2006/11/17 18:45:20 UTC
plugging more security holes in Derby
The 10.2 GRANT/REVOKE work was a big step forward in making Derby more
secure in a client/server configuration. I'd like to plug some more
security holes in 10.3. In particular, I'd like to focus on
authorization issues which the ANSI spec doesn't address. I would
appreciate feedback from the community: what do you think are the most
important outstanding security issues?
Here are the important issues which occur to me. I'm not sure that
GRANT/REVOKE will end up being the right way to plug these holes. Maybe
for some issues, maybe not for others. At this point I just want to
survey what's missing:
Missing privileges that are above the level of a single database:
- Create Database
- Shutdown System
Missing privileges specific to a particular database:
- Connect to that Database
- Shutdown that Database
- Create (in that Database) Java Plugins (currently
Functions/Procedures, but someday Aggregates and VTIs)
What other issues do you think we should list?
(Note that 10.2 gave us GRANT/REVOKE control over the following
database-specific issues, via granting execute privilege to system
procedures:
Jar Handling
Backup Routines
Admin Routines
Import/Export
Property Handling
Check Table )
I would appreciate the community's advice.
Thanks,
-Rick
Re: plugging more security holes in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Dag H. Wanvik wrote:
> Thanks for starting this discussion, Rick, I am also interested in
> looking at this.
>
> Rick Hillegas <Ri...@Sun.COM> writes:
>
Thanks, Dag!
>
>> ...
>>
>> Missing privileges that are above the level of a single database:
>>
>> - Create Database
>> - Shutdown System
>>
>
> Do we need a privilge for bootAll? BTW, I am not sure how bootAll
> property is supposed to work, I could not find it documented.
>
Agreed. I've added this to the list in DERBY-2109.
>
>> Missing privileges specific to a particular database:
>>
>> - Connect to that Database
>> - Shutdown that Database
>> - Create (in that Database) Java Plugins (currently
>> Functions/Procedures, but someday Aggregates and VTIs)
>>
>
> Maybe a separate privilege to upgrade a database would be desirable,
> at least hard upgrade. And a privilege to encrypt/re-encrypt a
> database?
>
Agreed. I've added this to the list in DERBY-2109 also.
> I assume the new database level system privileges will that require
> SQL authorization mode is active, not just the connection
> authorization, or...? In a way they are orthogonal, since system
> privileges are not defined by SQL. If bundled the name
> (derby.database.sqlAuthorization) would be slightly misleading..
>
My mind is trending that way too: GRANT/REVOKE would be a natural way to
control the per-database privileges even though it would be an extension
to the ANSI spec. Other databases use GRANT/REVOKE to control these
sorts of non-ANSI privileges. I could talk myself into extending the
meaning of derby.database.sqlAuthorization to embrace these non-ANSI
privileges: the mechanism (GRANT/REVOKE) is ANSI even though the
specific privileges aren't.
> The new system level system privileges (e.g. shutdown), would they
> also be enabled by SQL authorization mode?
>
> Dag
>
>
I will try to collect my thoughts on this topic and circulate them later
today.
Thanks!
-Rick
Re: plugging more security holes in Derby
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Thanks for starting this discussion, Rick, I am also interested in
looking at this.
Rick Hillegas <Ri...@Sun.COM> writes:
> The 10.2 GRANT/REVOKE work was a big step forward in making Derby more
> secure in a client/server configuration. I'd like to plug some more
> security holes in 10.3. In particular, I'd like to focus on
> authorization issues which the ANSI spec doesn't address. I would
> appreciate feedback from the community: what do you think are the most
> important outstanding security issues?
>
> Here are the important issues which occur to me. I'm not sure that
> GRANT/REVOKE will end up being the right way to plug these
> holes. Maybe for some issues, maybe not for others. At this point I
> just want to survey what's missing:
>
> Missing privileges that are above the level of a single database:
>
> - Create Database
> - Shutdown System
Do we need a privilge for bootAll? BTW, I am not sure how bootAll
property is supposed to work, I could not find it documented.
>
> Missing privileges specific to a particular database:
>
> - Connect to that Database
> - Shutdown that Database
> - Create (in that Database) Java Plugins (currently
> Functions/Procedures, but someday Aggregates and VTIs)
Maybe a separate privilege to upgrade a database would be desirable,
at least hard upgrade. And a privilege to encrypt/re-encrypt a
database?
I assume the new database level system privileges will that require
SQL authorization mode is active, not just the connection
authorization, or...? In a way they are orthogonal, since system
privileges are not defined by SQL. If bundled the name
(derby.database.sqlAuthorization) would be slightly misleading..
The new system level system privileges (e.g. shutdown), would they
also be enabled by SQL authorization mode?
Dag
>
> What other issues do you think we should list?
>
> (Note that 10.2 gave us GRANT/REVOKE control over the following
> database-specific issues, via granting execute privilege to system
> procedures:
>
> Jar Handling
> Backup Routines
> Admin Routines
> Import/Export
> Property Handling
> Check Table )
>
> I would appreciate the community's advice.
>
> Thanks,
> -Rick
>
--
Dag H. Wanvik
Sun Microsystems, Database Technology Group (DBTG)
Haakon VII gt. 7b, N-7485 Trondheim, Norway
Tel: x43496/+47 73842196, Fax: +47 73842101
Java routine security Was Re: plugging more security holes in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>> - Create (in that Database) Java Plugins (currently
>>> Functions/Procedures, but someday Aggregates and VTIs)
>>
>> Can you explain what this means, what security issue are you trying to
>> address?
> I'm concerned about being able to exploit security holes in code not
> supplied by Derby or the application. For instance, security holes in
> the jdk classes or in other applications hosted on the same vm.
This is actually due to an extension to the SQL standard (part 13) that
Derby and other databases provide. The ability to have the EXTERNAL NAME
for a Java routine to be a method in a class without specifying an
installed jar file name. The security model provided by SQL part 13 does
provide security by only allowing routines to resolve to a specific
installed jar file and providing the USAGE privilege on installed jar files.
Derby follows a different path, basically adding an installed jar file
to derby.database.classpath implicitly grants USAGE on that jar to
PUBLIC. The ability to perform this implicit grant is, as you say,
itself under GRANT/REVOKE because one must have EXECUTE permission on
the procedure to set the database property. Then in addition the class
in external name in Derby need not come from a jar file, but can be
resolved from the vm's classpath.
So one part of the solution would be to enhance Derby to support
installed jar names in EXTERNAL NAME and to implement the USAGE
privilege, following the SQL standard (part 13).
Then to address the resolution of routines that do not specify an
installed jar name in EXTERNAL NAME Derby could change from an implictly
adding the current classpath to the database classpath to a model where
it must explictily be added. Maybe fixed tokens like:
JRE - routines can resolve to any classes that start with
java. and javax.
CLASSPATH - routines can resolve to any classes that are on the vm's
classpath
E.g.
derby.database.classpath=<unset>
- No resolution of any routines that do not specify a jar file.
derby.database.classpath=SALES.SALES_FORCAST
- Only resolve methods from SALES.SALES_FORCAST
derby.database.classpath=JRE:SALES.SALES_FORCAST
- Only resolve methods from the JRE's java. and javax. classes and
classes in SALES.SALES_FORCAST
derby.database.classpath=CLASSPATH:SALES.SALES_FORCAST
- Only resolve methods from the current classpath, excluding java.
and javax classes, and those from SALES.SALES_FORCAST
derby.database.classpath=JRE:CLASSPATH:SALES.SALES_FORCAST
- Resolve methods as 10.2.
Dan.
Re: plugging more security holes in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Dan,
Thanks for your responses. Some more comments follow inline...
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>
>> Missing privileges specific to a particular database:
>>
>> - Shutdown that Database
>> - Encrypt that database
>> - Upgrade database
>
> I assume that when in SQL authorization mode these three should, by
> default, be limited to the database owner. I guess today with 10.2
> there is no such limitation in place. If that restriction was
> enforced, would there be any demand for the ability to grant the
> permission to other users?
Right, I think that by default these powers should be restricted to the
database owner. I also am having a hard time imagining why you would
want more than one person wielding these powers at any one time. The
only GRANT scenario I can think of, off the top of my head, would be
transferring these powers to a successor when the dba moves on to
another job. That case could probably be handled by telling users to set
up a special dba account for managing the application.
Thanks for bringing up these issues. They suggest that GRANT/REVOKE
might be overkill for authorizing these powers.
>
>> - Create (in that Database) Java Plugins (currently
>> Functions/Procedures, but someday Aggregates and VTIs)
>
> Can you explain what this means, what security issue are you trying to
> address?
I'm concerned about being able to exploit security holes in code not
supplied by Derby or the application. For instance, security holes in
the jdk classes or in other applications hosted on the same vm.
Regards,
-Rick
>
> Dan.
>
>
Re: plugging more security holes in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Missing privileges specific to a particular database:
>
> - Shutdown that Database
> - Encrypt that database
> - Upgrade database
I assume that when in SQL authorization mode these three should, by
default, be limited to the database owner. I guess today with 10.2 there
is no such limitation in place. If that restriction was enforced, would
there be any demand for the ability to grant the permission to other users?
> - Create (in that Database) Java Plugins (currently Functions/Procedures, but someday Aggregates and VTIs)
Can you explain what this means, what security issue are you trying to
address?
Dan.
Re: plugging more security holes in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Daniel John Debrunner wrote:
>>> Rick Hillegas wrote:
>>>
>>>> Missing privileges specific to a particular database:
>>>>
>>>> - Connect to that Database
>>>
>>> This is supported in Derby since 10.0. Connection level access by
>>> user name, either read-write, read-only or non.
>>>
>>> Dan.
>> Hi, Dan. I'm not sure I follow this. Can you point me at some Derby
>> user documentation for this feature?
>
> 10.2
>
> http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html
>
> 10.0
>
> http://db.apache.org/derby/docs/10.0/manuals/develop/develop108.html#HDRSII-CSECUR-36595
>
>
> Dan.
>
Thanks!
Re: plugging more security holes in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> I would like to continue the discussion about how we can tighten up
> Derby system privileges for the client/server case. I would appreciate
> the community's feedback.
>
> Here's where the discussion stands. We can imagine two big groupings of
> non-ANSI privileges not currently handled by our GRANT/REVOKE machinery:
>
> 1) System-wide privileges (e.g., Create Database, Boot all Databases,
> Shutdown System)
>
> 2) Per-database privileges (e.g., Shutdown Database, Encrypt Database,
> Create Java Plugins)
>
> What I would like to brainstorm now is this: how should we control these
> privileges? Here are some thoughts:
>
> 1) How to control system-wide privileges
>
> 1a) We could invent the concept of a Master Database. For the moment,
> let's be vague about who creates this database and when. In this Master
> Database, we could use GRANT/REVOKE to manage system-wide privileges.
>
> 1b) Alternatively, we could supply a Java interface (and default
> implementation) for managing system-wide privileges. This is how Derby
> manages users. Right now, for managing users we supply an interface,
> org.apache.derby.authentication.UserAuthenticator with a default
> implementation which the customer can override. For the moment, let's be
> vague about what we would put in this interface.
1c) Use Java Permissions, e.g.
org.apache.derby.security.DatabasePermission(String name)
target names
create - allows databases to be created
shutdown - allows database to be shutdown
Haven't thought it through a great deal, but utilizing an existing
mechanism should be considered.
Dan.
Re: plugging more security holes in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
I would like to continue the discussion about how we can tighten up
Derby system privileges for the client/server case. I would appreciate
the community's feedback.
Here's where the discussion stands. We can imagine two big groupings of
non-ANSI privileges not currently handled by our GRANT/REVOKE machinery:
1) System-wide privileges (e.g., Create Database, Boot all Databases,
Shutdown System)
2) Per-database privileges (e.g., Shutdown Database, Encrypt Database,
Create Java Plugins)
What I would like to brainstorm now is this: how should we control these
privileges? Here are some thoughts:
1) How to control system-wide privileges
1a) We could invent the concept of a Master Database. For the moment,
let's be vague about who creates this database and when. In this Master
Database, we could use GRANT/REVOKE to manage system-wide privileges.
1b) Alternatively, we could supply a Java interface (and default
implementation) for managing system-wide privileges. This is how Derby
manages users. Right now, for managing users we supply an interface,
org.apache.derby.authentication.UserAuthenticator with a default
implementation which the customer can override. For the moment, let's be
vague about what we would put in this interface.
I tend to think that (1a) is heavyweight while (1b) is more flexible.
What do other people think? What other suggestions do people have for
managing system-wide privileges?
2) How to control database-wide privileges
2a) We could use GRANT/REVOKE to manage database-wide privileges.
2b) This is (2a) with a twist: One of the database-wide privileges
(Create Java Plugin) could be modelled as a per-schema privilege.
Other databases GRANT and REVOKE database-wide privileges. This,
however, extends the ANSI spec in vendor-specific ways. Is that OK for
Derby to do? In addition, DB2, Oracle, and Postgres scope the Create
Java Plugin privilege at the database rather than the schema level. For
these reasons, I think that (2a) would be fine. What do other people
think? What other suggestions do people have for managing database-wide
privileges?
Thanks for your feedback. Please don't be offended if I don't reply
until next week--I'm going on Thanksgiving holiday soon.
Regards,
-Rick
Re: plugging more security holes in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>
>>> Missing privileges specific to a particular database:
>>>
>>> - Connect to that Database
>>
>> This is supported in Derby since 10.0. Connection level access by user
>> name, either read-write, read-only or non.
>>
>> Dan.
> Hi, Dan. I'm not sure I follow this. Can you point me at some Derby user
> documentation for this feature?
10.2
http://db.apache.org/derby/docs/10.2/devguide/cdevcsecure865818.html
10.0
http://db.apache.org/derby/docs/10.0/manuals/develop/develop108.html#HDRSII-CSECUR-36595
Dan.
Re: plugging more security holes in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>
>> Missing privileges specific to a particular database:
>>
>> - Connect to that Database
>
> This is supported in Derby since 10.0. Connection level access by user
> name, either read-write, read-only or non.
>
> Dan.
Hi, Dan. I'm not sure I follow this. Can you point me at some Derby user
documentation for this feature?
Thanks,
-Rick
Re: plugging more security holes in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> Missing privileges specific to a particular database:
>
> - Connect to that Database
This is supported in Derby since 10.0. Connection level access by user
name, either read-write, read-only or non.
Dan.
Re: plugging more security holes in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
I have attached a first draft of a functional spec to the JIRA for this
topic: DERBY-2109. This first draft attempts to summarize the discussion
so far. Would appreciate continued feedback from the community.
Thanks,
-Rick
Re: plugging more security holes in Derby
Posted by Daniel John Debrunner <dj...@apache.org>.
Rick Hillegas wrote:
> When we introduce system-wide and database-specific privileges we will
> need at least one more knob. This additional knob will control whether
> these privileges are checked or whether legacy applications continue to
> behave as they did in 10.2. Let us suppose this is another property.
> Here are two ways to handle this knob:
>
> 3a) It could be boolean, that is, take true/false values just like
> /derby.database.sqlAuthorization./
>
> 3b) Alternatively, it could be an integer, specifying the
> privilege-checking level of the Derby engine.
>
> Approach (3b) seems more flexible to me. It would allow us to add more
> system/database privileges in future releases. Let's call this knob
> /derby.system.privLevel/. It could behave as follows:
>
> derby.system.privLevel unspecified (Default behavior. We don't check for
> database or system privileges.)
> derby.system.privLevel=10.2 (Default behavior above.)
> derby.system.privLevel=10.3 (We check for the database and system
> privileges introduced in 10.3.)
> derby.system.privLevel=10.4 (We check for the database and system
> privileges handled by the previous release as well as any new database
> and system privileges introduced in 10.4.)
>
> Please let me know what you think about this proposal and whether you
> have other ideas about how to manage the upgrading of legacy
> applications to 10.3.
I think more mode settings is not a good idea. I would view this as
closing security holes that make the existing SQL authorization mode
insecure. For all of these we can provide instructions on how to modify
10.2 applications to work in 10.3.
Dan.
Re: plugging more security holes in Derby
Posted by da...@sonic.net.
I'm sure I'm missing something, but all your proposals sound pretty good
to me on the face of it.
David
> Thanks to Dan and Dag, I believe that Derby system privileges are
> beginning to look much simpler. I would like to continue the discussion
> about how we can plug more security holes in our client/server
> configuration. So far we have discussed the following:
>
> 1) System-wide privileges (shutdown system, shutdown all databases,
> create databases).
>
> 2) Database-specific privileges (shutdown, encrypt, upgrade, create
> plugins).
>
> I would like to add another topic to the discussion:
>
> 3) Knobs. What kind of knobs do we need to control default behavior and
> make upgrade smooth?
>
> Here then are some more thoughts:
>
> ------------ 1) System-wide Privileges ----------------------
>
> The alternatives so far:
>
> 1a) GRANT/REVOKE in a master database
> 1b) A user-implementable api modelled on
> org.apache.derby.authentication.UserAuthenticator
> 1c) Java permissions
>
> Some comparisons:
>
> (1a)
> + Familiar api
> - Non-standard extensions to that api
> - Heavyweight
>
> (1b)
> + Flexible
> + Easy to extend
> + Master database (something like (1a)) could be added as a special
> implementation
> + Modelled on an existing Derby api
>
> (1c)
> + Standard mechanism
> + Simple administration
> + Easy to extend
> - Requires that the whole VM runs under a SecurityManager
>
> I don't feel that it would be too onerous to require a SecurityManager
> for the whole VM. I prefer (1c) over the other approaches because it is
> a standard mechanism.
>
> ------------ 2) Database-specific Privileges ----------------------
>
> The alternatives so far:
>
> 2a) GRANT/REVOKE extensions
> 2b) Limiting privileges to the database owner
>
> Some comparisons:
>
> (2a)
> + Familiar mechanism
> - Heavyweight overkill for most of the privileges
>
> (2b)
> + Simple
> + Adequate for most of the privileges
> - Perhaps overly restrictive for Plugin privilege
> - How to migrate database ownership if DBA kicked upstairs to be CTO
>
> I prefer (2b) because it is simple. I think we could address its issues
> as follows:
>
> i) Treat the Plugin power as a system-wide privilege rather than a
> database-specific privilege. Manage Plugin power using Java permissions
> per (1c).
>
> ii) We could add a warning paragraph to the security section of the
> Developer's Guide. This paragraph would advise client/server users to
> create special dba accounts for their databases so that they can migrate
> database powers to a new dba when the old dba moves on to new
> responsibilities. If this situation turns out to be a problem, a
> follow-on release could introduce some mechanism for migrating the
> ownership of databases.
>
> ------------ 3) Knobs ----------------------
>
> In 10.2 we introduced a new knob, a property called
> /derby.database.sqlAuthorization/. Its default setting (false) preserves
> legacy Derby behavior, i.e., permissions are not GRANTed and existing
> client/server applications continue to function in the old, insecure way
> that is appropriate for embedded applications. Setting this property to
> true enables permissions checking.
>
> When we introduce system-wide and database-specific privileges we will
> need at least one more knob. This additional knob will control whether
> these privileges are checked or whether legacy applications continue to
> behave as they did in 10.2. Let us suppose this is another property.
> Here are two ways to handle this knob:
>
> 3a) It could be boolean, that is, take true/false values just like
> /derby.database.sqlAuthorization./
>
> 3b) Alternatively, it could be an integer, specifying the
> privilege-checking level of the Derby engine.
>
> Approach (3b) seems more flexible to me. It would allow us to add more
> system/database privileges in future releases. Let's call this knob
> /derby.system.privLevel/. It could behave as follows:
>
> derby.system.privLevel unspecified (Default behavior. We don't check for
> database or system privileges.)
> derby.system.privLevel=10.2 (Default behavior above.)
> derby.system.privLevel=10.3 (We check for the database and system
> privileges introduced in 10.3.)
> derby.system.privLevel=10.4 (We check for the database and system
> privileges handled by the previous release as well as any new database
> and system privileges introduced in 10.4.)
>
> Please let me know what you think about this proposal and whether you
> have other ideas about how to manage the upgrading of legacy
> applications to 10.3.
>
> Thanks,
> -Rick
>
>
Re: plugging more security holes in Derby
Posted by Rick Hillegas <Ri...@Sun.COM>.
Thanks to Dan and Dag, I believe that Derby system privileges are
beginning to look much simpler. I would like to continue the discussion
about how we can plug more security holes in our client/server
configuration. So far we have discussed the following:
1) System-wide privileges (shutdown system, shutdown all databases,
create databases).
2) Database-specific privileges (shutdown, encrypt, upgrade, create
plugins).
I would like to add another topic to the discussion:
3) Knobs. What kind of knobs do we need to control default behavior and
make upgrade smooth?
Here then are some more thoughts:
------------ 1) System-wide Privileges ----------------------
The alternatives so far:
1a) GRANT/REVOKE in a master database
1b) A user-implementable api modelled on
org.apache.derby.authentication.UserAuthenticator
1c) Java permissions
Some comparisons:
(1a)
+ Familiar api
- Non-standard extensions to that api
- Heavyweight
(1b)
+ Flexible
+ Easy to extend
+ Master database (something like (1a)) could be added as a special
implementation
+ Modelled on an existing Derby api
(1c)
+ Standard mechanism
+ Simple administration
+ Easy to extend
- Requires that the whole VM runs under a SecurityManager
I don't feel that it would be too onerous to require a SecurityManager
for the whole VM. I prefer (1c) over the other approaches because it is
a standard mechanism.
------------ 2) Database-specific Privileges ----------------------
The alternatives so far:
2a) GRANT/REVOKE extensions
2b) Limiting privileges to the database owner
Some comparisons:
(2a)
+ Familiar mechanism
- Heavyweight overkill for most of the privileges
(2b)
+ Simple
+ Adequate for most of the privileges
- Perhaps overly restrictive for Plugin privilege
- How to migrate database ownership if DBA kicked upstairs to be CTO
I prefer (2b) because it is simple. I think we could address its issues
as follows:
i) Treat the Plugin power as a system-wide privilege rather than a
database-specific privilege. Manage Plugin power using Java permissions
per (1c).
ii) We could add a warning paragraph to the security section of the
Developer's Guide. This paragraph would advise client/server users to
create special dba accounts for their databases so that they can migrate
database powers to a new dba when the old dba moves on to new
responsibilities. If this situation turns out to be a problem, a
follow-on release could introduce some mechanism for migrating the
ownership of databases.
------------ 3) Knobs ----------------------
In 10.2 we introduced a new knob, a property called
/derby.database.sqlAuthorization/. Its default setting (false) preserves
legacy Derby behavior, i.e., permissions are not GRANTed and existing
client/server applications continue to function in the old, insecure way
that is appropriate for embedded applications. Setting this property to
true enables permissions checking.
When we introduce system-wide and database-specific privileges we will
need at least one more knob. This additional knob will control whether
these privileges are checked or whether legacy applications continue to
behave as they did in 10.2. Let us suppose this is another property.
Here are two ways to handle this knob:
3a) It could be boolean, that is, take true/false values just like
/derby.database.sqlAuthorization./
3b) Alternatively, it could be an integer, specifying the
privilege-checking level of the Derby engine.
Approach (3b) seems more flexible to me. It would allow us to add more
system/database privileges in future releases. Let's call this knob
/derby.system.privLevel/. It could behave as follows:
derby.system.privLevel unspecified (Default behavior. We don't check for
database or system privileges.)
derby.system.privLevel=10.2 (Default behavior above.)
derby.system.privLevel=10.3 (We check for the database and system
privileges introduced in 10.3.)
derby.system.privLevel=10.4 (We check for the database and system
privileges handled by the previous release as well as any new database
and system privileges introduced in 10.4.)
Please let me know what you think about this proposal and whether you
have other ideas about how to manage the upgrading of legacy
applications to 10.3.
Thanks,
-Rick