db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roy.Mi...@comcast.net
Subject Re: Derby secure by default
Date Mon, 19 Sep 2011 19:51:26 GMT
Installing a new version should always be backward compatible and not break anything in existing
applications.  If things don't work this way, it's bound to be (unncessarily) disruptive
to some, and especial ly those less sophisticated and less able to figure out and fix problems.
  I see no reason why anyon e who wishes to utilize the new capabil ities would have any
problem with setting the new property when they are ready to do so.  Security is obviously
important, especially for networked applications.  I think it's also important not to do
anything that interferes with embedded applications designed to  require ZERO administration.

----- Original Message -----
From: "Rick Hillegas" <rick.hillegas@oracle.com> 
To: "Derby Discussion" <derby-user@db.apache.org> 
Sent: Monday, September 19, 2011 12:39:07 PM 
Subject: Derby secure by default 

The Derby developers are considering introducing a single master 
security property. Turning this property on will enable most Derby 
security mechanisms: 

1) Authentication - Will be on, requiring username/password credentials 
at connection time. Derby will supply a default authentication mechanism. 

2) SQL authorization - Will be on, hiding a user's data from other 
people. In addition, Derby will support more SQL Standard protections 
for Java routines. 

3) File permissions - Will be tightened as described by DERBY-5363. 

4) PUBLIC -This keyword will not be allowed as a user name. 

5) SSL/TLS encryption - Will shield client/server traffic. 

6) Server administration -  Will require credentials. 

When the property is off, Derby will behave as it does today: 
Authentication, authorization, and network encryption will be off, file 
permissions will inherit defaults from the account which runs the VM, 
PUBLIC will be a legal user name, and server administration won't need 

This new master property will make it easier to configure a more secure 
application. We want to introduce the property in an upcoming 10.x 
release, where it will default to being off. That means that it won't 
cause compatibility problems. 

Later on, we might change the default for this property so that it would 
normally be turned on. This would make Derby more secure out of the box 
at the cost of breaking existing applications. Many applications would 
need to explicitly turn the property off in order to run as they did 
previously. Release notes would document this behavioral change and we 
would bump the major release id from 10 to 11 in order to call attention 
to the change. 

We would like your feedback on this trade-off between security out of 
the box versus disruption. Should this extra security be enabled by default? 


View raw message