db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: Installing a SecurityManager by default when the server boots
Date Thu, 08 Nov 2007 20:19:43 GMT
To clarify the statement I received and passed onto the community.  The 
'positive reaction'  was to the OR case:
  ...Or should we consider turning off this feature in the upcoming 10.3 
maintenance release?

With the current behavior (starting the security manager by default), 
this group is looking at having their upgrade installer add the 
-noSecurityManager flag to the NS startup scripts for their existing 
installations.  In addition they are discussing issuing a caution about 
this behavior in their release notes in case a customer has created 
their own startup script and do not specify a security manager.

Stanley Bradbury wrote:
> I obtained a positive reaction from a group with a large install base 
> that will be transitioning to version 10.3.  Derby and Network Server 
> are used with sample code and readily available for use as a business 
> system data store. The statement I received is:
> "I am all for it.  Anything that will mean not breaking customers out 
> of the box is a good thing."
> Rick Hillegas wrote:
>> As of release 10.3, when you boot the network server from the command 
>> line, the server installs a Java SecurityManager with a default 
>> policy. This change (DERBY-2196) limits the ability of hackers, 
>> connecting from arbitrary machines, to use Derby to corrupt the 
>> environment in which it is running. In addition, this change provides 
>> a foundation on which we can add more security features 
>> incrementally. As a result of this change, we have learned more about 
>> how Derby behaves when run under a SecurityManager--that in turn, has 
>> helped us discover more permissions which we need to add to the 
>> template used as a starting point for configuring a Derby security 
>> policy.
>> Unfortunately, this change has proved painful to some users. See, for 
>> instance, DERBY-3086 and the ongoing discussion on DERBY-3083.
>> Now that we have some experience with the 10.3 release, I would like 
>> to ask the community to review the wisdom of this change. Do we still 
>> think that this is the correct default behavior? Or should we 
>> consider turning off this feature in the upcoming 10.3 maintenance 
>> release?
>> Thanks,
>> -Rick

View raw message