db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: SecurityManager incompatibility (was Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade)
Date Fri, 01 Jun 2007 18:09:35 GMT
Thanks to Dan and David for your advice. Some more musings follow:

David Van Couvering wrote:
> 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.
Our release process doesn't factor in what I would call a beta test. To 
my way of thinking, a real beta program would require a lot of 
preparation, which we haven't done, and a lot of monitoring, which we 
haven't planned.

In short, I don't think our release process will give you the feedback 
you want here. Possibly we would get quick, negative feedback that (2) 
is the wrong approach. But I don't think we'll get sufficient feedback 
to feel confident that (2) is the right approach.
> 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.
I can see that many applications would fit this profile. I am worried, 
however, about other applications which have been lulled into a laxer 
process by Cloudscape/Derby's long track record of painless upgrades.
> 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
> own.
> 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
> authentication).
> David
I continue to be inclined to go with (3). The original issue 
(DERBY-2196) was a request to install a security manager if the user 
forgot to. I still think that's a good idea by itself. The follow-on 
request was to stop giving the user a false sense of security. I think 
that's a broader issue, some of whose details are mentioned by 
DERBY-1056. Given the strong reaction to this email thread, our 
inability to measure the residual exposure, and the lateness in the day, 
I think that we should separate the two issues.

I volunteer to do (3). If someone else wants to volunteer to do (2), I 
will stand aside.

> 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