db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering" <da...@vancouvering.com>
Subject Re: SecurityManager incompatibility (was Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade)
Date Thu, 31 May 2007 18:47:38 GMT
I am also torn between 2 and 3 but am leaning towards 2, especially if
we document this is what we should do.

Does Derby 10.3 have a beta period?  If we can get a strong amount of
users testing Derby 10.3 in beta we might get some good feedback if we
go with option 2.  If we start with 3 from the get-go,  nobody would
give us feedback (as it continues to work the way it did in 10.2), but
we could be complicit in letting users expose themselves in a
dangerous way.

Like I said, if you're making your DB available on machines other than
localhost, you are running in a non-development mode.  I imagine the
following scenario where I am your standard IT guy eating donuts in
the server room:

- I upgrade to 10.3 in a staging area (anyone who does a live upgrade
without testing is definitely on the FAR edge of the bell curve)
- 10.3 doesn't start up.  WTF?
- I read the error log.  It explains why it didn't start up, what the
risk is, and what you can do about it (explicitly turn off
authentication or enable authentication)

The user then has the choice.  If his applications just don't do any
authentication and it's a big change to modify the apps, then I can
explicitly turn off authentication using
derby.connection.requireAuthentication = false.  But now I am aware of
my risk.  I can make plans to enable authentication in my apps and get
on the security bandwagon.

At least we (the Derby team) won't silently let users expose
themselves -- we've given them their warning and now they are on their

So, my 2 cents: go with number 2.  A gentle slap in the face, and they
can make their choice.  One caveat: the error message needs to be
*very* clear with *why* we did this (describe the exposure) and *what*
the user can do about it (explicitly enable or disable


On 5/31/07, Daniel John Debrunner <djd@apache.org> wrote:
> 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.

View raw message