db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: Derby secure by default
Date Mon, 19 Sep 2011 17:38:28 GMT
I am not sure how it applies to all of these points, but I am wondering 
if secure by default should be implemented on a per database basis 
rather than a system level basis?  It seems wierd that security could
change based on how the next embedded startup set a flag.

What about having the property be part of what user requests at database
creation time?  And maybe allow some secure way either disable or enable 
it.  The discussion could continue on what the default for a newly 
created database would be.  At least for point 1-4 seems to make more 
sense, not sure about 5,6.

I personally think many of these points make most sense for derby 
network server.  While many possibly get in the way for many zero-admin
embedded applications.  Since we have one codeline for the most part
for both it is hard to have one default.


Rick Hillegas wrote:
> 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 
> credentials.
> 
> 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?
> 
> Thanks,
> -Rick
> 
> 


Mime
View raw message