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 Wed, 30 May 2007 22:57:15 GMT
On 5/30/07, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> I don't know how to measure the residual exposure here. I have not had
> much success trawling derby-user for advice.

You might try nbusers (and the matching list on Eclipse).  There seem
to be more database users there than on derby-user :)   Seriously.

>> The motivation for flunking the boot was to avoid giving the customer a
> false sense of security. This was briefly touched on in comments
> attached to DERBY-2206 (January 26, 2007, 8:05 am and 9:20 am). Maybe we
> were seeing the glass as half empty and should, instead, be happy that
> the glass is half full.
> >
If we were starting from scratch, I would be all for requiring
authentication *and* a security manager.  That is the Right Thing to
Do.

But the problem is we have an existing installed base, and if we do
this it will Break Things.

I can envision deprecating support for an unauthenticated network
server.  This would allow folks like us over in NetBeans to make
preparations and adjust.  I would ultimately like to see Derby secure
by default, and you have to explicitly "opt out" of running in a
secure environment.

> 4) Boot an unauthenticated server and install a security manager
> regardless of whether we're listening on localhost. Here the glass is
> half full and we remove the incompatibility.

This makes me a little nervous.  It seems to me that if someone is
opening up the server to non-local connections, they are doing
something more than development, and they really should be running
with authentication.

But yes, this would break some existing users, and at least with a
security manager installed they are less exposed than they were
before.

And, we could deprecate support for an unauthenticated server -- print
out a warning, and remove support in the next release.  I understand
printing out a warning is not the most noticed thing in the world, but
it would help.

It's a difficult call.  The one place where breaking compatibility
seems justified is when there is a real security hole when users run
with the default configuration.

David

>
> Regards,
> -Rick
>
>

Mime
View raw message