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 Fri, 01 Jun 2007 18:41:53 GMT
Rick Hillegas wrote:
> 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).

With 3) can we restrict the file permissions in the default policy file. 
Currently it is:

permission java.io.FilePermission "${derby.system.home}${/}-", 
permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete";

The <<ALL FILES>> is dangerous if the server is running without 
authentication and listening to remote clients (as 3) allows).
(Just imagine if the server is started as super-user!)

How about just

permission java.io.FilePermission "${derby.system.home}${/}-", 
permission java.io.FilePermission "${java.io.tmpdir}${/}-", 

This would at least limit access to the derby.system.home and temp dirs.

Note that if derby.system.home is not set the network server sets it to 


View raw message