db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stanley Bradbury <Stan.Bradb...@gmail.com>
Subject Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade
Date Tue, 29 May 2007 19:55:17 GMT
Mike Madrigaling wrote:
> Dag H. Wanvik wrote:
>> Hi,
>> Stanley Bradbury <Stan.Bradbury@gmail.com> writes:
>>> I feel strongly that the restrictions implemented by DERBY-2264 must
>>> be tied to sqlAuthorization (or a new property of it's own) being
>>> turned on.  The restrictions need to be optional at upgrade otherwise
>> I understand your concerns. I addressed the upgrade issue several
>> times in the discussion of this issue, but felt the community
>> preferred the semantics which are currently implemented, landing on
>> the side of a sensible secure-by-default behavior. Options:
>>     - label this a major release (11.0), lowering the expectancy for a
>>       painless upgrade with users.
>>     - postpose the 10.3 release and change the semantics to something
>>       else (tie enforcement to sqlAuthorization, introduce new
>>       property to turn this checking off (default on) or vice versa)
>>     - release it as it stands, but make a follow-up release with some
>>       knob to allow users to disable it; making sure to call this out
>>       in release notes. Note: since hard upgrade is among the operations
>>       restricted, users would likely (although not necessarily) get
>>       some hint of the issue early on ;)
>>     - pull the feature from 10.3 (I'd love to avoid that ;)
>>     - others?
>> We need to decide pretty quick; this is a bit late in the game.. What
>> say others?
> I agree.  Let's somehow mark this issue as a blocker for the 10.3 
> release.  I am not saying a change is necessary for the release, only
> some consensus on the right approach.  It is not clear to me that
> the issue was fully understood, or noticed by the community at that 
> point.
> I am ok with delaying the release get discussion/consensus on this issue.
>> Thanks,
>> Dag
>>> the feature will, by default, break compatibility for some
>>> applications using connection based authentication.  Put simply,
>>> removing the ability for any user to shutdown or upgrade a database
>>> will cause failures in systems that depend on that functionality.  I
>>> am certain that many Derby users like the near-zero-admin nature of
>>> the old authentication system.  This feature introduces an
>>> administrative account.  Dag originally suggested the feature be tied
>>> to sqlAuthorization (thank-you, Dag) when he noted that the patch
>>> caused some tests in derbyall to fail.  Now that I have had time work
>>> with the feature and better evaluate the impact I see this as
>>> necessary for compatibility.  This issue will be logged in JIRA before
>>> long but I chose to begin the discussion outside of JIRA to increase
>>> mailbox visibility.  Any opinions - agreements/objections?
I'll open a LIRA blocker issue on this later today (after all the 
meetings are over *whew*).  I'll use the Title/Summary:  Make DO 
restrictions from Derby-2264 optional at upgrade.  I do not believe that 
existing Derby Users are aware of this change and I think the impact of 
will have is greater than anyone suspects.  For instance, it appears 
that if ';upgrade=true' is hardcoded in the connection URL that only the 
DO account will be able to access the database.  I suspect there are 
other issues like this as well.

I will also add some additional information and suggest that as a 
sub-task (or super task - is that possible?) be added regarding deciding 
as a community how we will introduce changes like this.  By 'like this' 
I mean changing previous behavior.  More to the point is; defining a 
deprecation process that allows the Derby user-base to obtain a new 
release, assess the impact of 'changes' (the Release Notes will be the 
introduction of these issues for many users) and, by making the changes 
optional (activated by a property), allow applications that require 
significant rework to upgrade  then begin  work on  what maybe several 
months to a year of coding and testing to become compliant with the 

View raw message