David Van Couvering wrote:
> On Nov 8, 2007 12:13 PM, Kathey Marsden <[EMAIL PROTECTED]>
wrote:
>> 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.."
https://issues.apache.org/jira/secure/attachment/12362564/secureServer.html
Anything that fails outside of those limitations is a bug and should be
fixed.
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
AccessControlException.
Dan.
