db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "DerbyTenThreeRelease" by DanDebrunner
Date Thu, 24 May 2007 17:38:48 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by DanDebrunner:
http://wiki.apache.org/db-derby/DerbyTenThreeRelease

The comment on the change is:
Make the incompatiblity section more generic than just upgrading from 10.2

------------------------------------------------------------------------------
   * TenThreeApplicationTesting
  
  
- == Incompatibilities Upgrading from 10.2 ==
+ == Incompatibilities Upgrading from Previous Releases ==
  
- The Secure Server work ([https://issues.apache.org/jira/browse/DERBY-2196 DERBY-2196]) introduces
the following incompatibility during upgrade from release 10.2:
+ The Secure Server work ([https://issues.apache.org/jira/browse/DERBY-2196 DERBY-2196]) introduces
the following incompatibility during upgrade from an older Derby release:
  
  || '''Scenario''' || '''Old behavior''' || '''New behavior''' || '''Customer needs to make
these changes...''' ||
  ||  '''Unsecure with authentication'''|| In this scenario, !NetworkServerControl is the
main entry point for the VM and the VM starts up without a !SecurityManager. However, the
customer has set the system property derby.connection.requireAuthentication=true|| The server
comes up as before. However, under the hood,  !NetworkServerControl installs a !SecurityManager.
This may affect the running of customer-written procedures and functions. Application code
within routines will no longer be able to perform operations that require security checks
like file i/o, system-property-reading, classloading, etc.. || The customer does not need
to do anything if her routines are not perfoming such operations. If her routines are performing
such operations then there are (at least) two choices. 1) Bring the server up with the -noSecurityManager
flag if the !SecurityManager causes her problems--for instance, if she does not want to add
privileged blocks to her procedures and functions. 2)
  Bring the server up with her own security manager and policy file. ||
  ||  '''Unsecure with no authentication'''|| In this scenario, !NetworkServerControl is the
main entry point for the VM and the VM starts up without a !SecurityManager. In addition,
the system property derby.connection.requireAuthentication is not set to true|| The server
fails to come up because user authentication is not turned on.|| The customer must either
turn on user authentication or bring the server up with the -noSecurityManager flag. ||
  
  
- The DBA Powers work ([https://issues.apache.org/jira/browse/DERBY-2264 DERBY-2264]) introduces
the following incompatibility during upgrade from release 10.2:
+ The DBA Powers work ([https://issues.apache.org/jira/browse/DERBY-2264 DERBY-2264]) introduces
the following incompatibility during upgrade from an older Derby release:
  
  ||  '''Privilege'''|| '''Previous behavior...'''|| '''Behavior after these changes when
authentication is enabled...'''|| '''Impacts...'''|| '''How to upgrade application...'''||
  ||  '''shutdown database'''|| Anyone who could connect could shutdown a database.|| A database
can be shutdown only by  its owner.|| All applications which run with database or system authentication.||
Anyone who must shutdown the database must connect as the Database Owner. '''Risk that the
database owner is not a valid user in the authentication scheme, typically APP''' ||
  ||  '''upgrade database'''|| Anyone who could connect could upgrade the database.|| Only
the Database Owner can upgrade the database.|| All applications which run with database or
system authentication.|| Anyone who must upgrade the database must connect as the Database
Owner. '''Risk that the database owner is not a valid user in the authentication scheme, typically
APP'''||
- ||  '''encrypt database'''|| Anyone who could connect could encrypt the database.|| Only
the Database Owner can encrypt or re-encrypt the database.|| All applications which run with
database or system authentication.|| Anyone who must encrypt the database must connect as
the Database Owner.  '''Risk that the database owner is not a valid user in the authentication
scheme, typically APP'''||
+ ||  '''encrypt existing database''' || Anyone who could connect could encrypt an existing
database (this was a new feaute added in 10.2) || Only the Database Owner can encrypt or re-encrypt
the database.|| All applications which run with database or system authentication.|| Anyone
who must encrypt the database must connect as the Database Owner.  '''Risk that the database
owner is not a valid user in the authentication scheme, typically APP'''||
  
+ Risk of DBO being a non-authenticated user after upgrade to 10.3.
+ 
+ || '''Old Release''' || '''Risk of invalid DBO''' ||
+ || 10.0, 10.1 || After upgrade the DBO will be the user performing the upgrade which means
the DBO will either be an authenticated user or authentication is not enabled. '''No risk'''
of the the DBO not being a valid user. ||
+ || 10.2 without authentication || No authentication so '''no risk''' of the the DBO not
being a valid user. ||
+ || 10.2 with authentication || The DBO will be the user who created the database or upgraded
it from 10.0 or 10.1. '''Risk''' exists if authentication was changed since the database was
created or updated from 10.0/10.1. Risk is probably less likely if the application is using
SQL authorization as the DBO plays a critical role in that setup. ||
+  
+ Any change to authentication in a 10.3 database must ensure that the DBO remains a valid
user. With SQL authorization enabled this is more likely because typically the DBO is the
only user who can change authentication (through system procedures). Though the DBO could
accidently set up authentication that excluded herself.
+  
+ 

Mime
View raw message