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: SecurityManager incompatibility (was Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade)
Date Thu, 31 May 2007 16:34:56 GMT
Rick Hillegas wrote:
> So far there doesn't seem to be much controversy about installing a 
> security manager if the user forgets to. Please correct me if the 
> security-manager-installation is controversial too.
> 
> The controversy I'm aware of seems to be this: should we fail to boot 
> the server if authentication is turned off? There seem to be several 
> proposed solutions. All of these proposals install a security manager at 
> server-boot time if the user neglects to. All of these proposals also 
> provide a command line option which forces the server to boot even if 
> Derby thinks it's a bad idea:
> 
> 1) Flunk the boot if authentication is turned off (current 10.3 behavior).
> 
> 2) Flunk the boot only if authentication is turned off and the server is 
> listening on something other than localhost.
> 
> 3) Don't flunk the boot.
> 
> There is a related issue of whether to print/log a diagnostic if the 
> server comes up in what it considers an unsafe configuration. I think 
> this can be addressed by DERBY-1056 later on.
> 
> I vote for option (3). It completely removes the incompatibility which 
> people are concerned about.

3) would make the current flag '-noSecurityManager' actually mean what 
it says, always a good thing. Currently it actually means "no security 
manager *and* ignore the fact no authentication is set up".

I'm torn between 2) and 3)

2) Seems a good compromise and corresponds to the unconfigured state.

3) My fear is that this is a big exposure to security issues with Derby, 
however the user has made configuration changes and it is documented 
that one should setup a security manager and authentication when making 
such a change.

Another factor that could be brought in is if 
derby.connection.requireAuthentication is set to *false*. This is an 
explicit request to have no authentication, rather than a default. Thus 
if the property was set to false then allow "no authentication" boots. I 
don't think this will help backwards compatibility (unlikely to have the 
property set to false) but it may allow existing users that want no 
authentication to use 10.3 easily.

Dan.

Mime
View raw message