db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Installing a SecurityManager by default when the server boots
Date Fri, 09 Nov 2007 06:01:28 GMT
David Van Couvering wrote:

 > On Nov 8, 2007 12:13 PM, Kathey Marsden <kmarsdenderby@sbcglobal.net> 
 >> I wonder if it would be acceptable to have no security manager for a
 >> server that only accepts connections from localhost, but keep it enabled
 >> if remote connections are enabled.

> I like this, this seems like a good compromise.  If you are using
> localhost, then you are using it for personal development, testing and
> use.  If you listen outside of localhost, then you're up and running
> and secure by default seems much more important.

Listening on localhost without a security manager re-introduces a 
security hole. Any other user on the same machine can now access your 
files, modify your scripts, binaries etc. to add malicious code.

It's worth re-visiting the functional spec (attached to DERBY-2196) to 
see what the intended limitations are with the default security manager:

"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.."


Anything that fails outside of those limitations is a bug and should be 

I believe any proposed change in this area should consider carefully 
what it is trying to achieve, any security risks (re)introduced by the 
change and how it will affect most applications.

I would guess most applications are not writing SQL routines that 
require security checks, any SQL routines are either performing 
calculations on or manipulation of values or are server-side JDBC 
routines. That's why I believe the default security file is a "free 
lunch" for most applications, in the three months that 10.3 has been 
released there has not been a single user wondering why or complaining 
that their SQL routine stopped working in 10.3 due to an 


View raw message