Make DBO restrictions from Derby-2264 optional for upgrades
-----------------------------------------------------------
Key: DERBY-2728
URL: https://issues.apache.org/jira/browse/DERBY-2728
Project: Derby
Issue Type: Bug
Affects Versions: 10.3.0.0
Reporter: Stan Bradbury
The DBO restrictions implemented in Derby-2264 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 installations depend on the near-zero-admin nature of the old
authentication system. This feature introduces an administrative account that
will require changes in some existing designs. I think this feature will have
is greater negative impact on existing systems than anyone suspects and these
restrictions should be made optional.
==== The email thread comments on derby-dev:
>>>> Email from Rick Hillegas and thread:
Daniel John Debrunner wrote:
> Dag H. Wanvik wrote:
>> Hi,
>>
>> Stanley Bradbury <[EMAIL PROTECTED]> 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:
>
> Was there any discussion outside of comments in DERBY-2264? I looked in the
> archives but couldn't see any between 2007/02/13 and 2007/02/20. I picked
> that date range because on 02/20 you said in DERBY-2264
>
> "Right, it seems both Dan and Rick are less concerned than me about the
> compatibility here issue, so I rest my case. "
>
> That was the first comment since 02/13, however, I don't see how my single
> comment in DERBY-2264 could lead you to that conclusion, I thought it's was
> just factual about authentication states. I'm sure there must have been a
> discussion elsewhere, but I can't find it at the moment.
>
> Dan.
>
>
>
I don't see any other discussion beyond what appears in DERBY-2264. I like
Dag's original proposal that we should restrict DBO powers only if both
authentication and authorization are enabled. I don't like the idea of adding
another security knob for this.
Regards,
-Rick
>>>> Email from Stan Bradbury and thread (with spell checker changes
undone):
Mike Matrigali wrote:
>
>
> Dag H. Wanvik wrote:
>> Hi,
>>
>> Stanley Bradbury <[EMAIL PROTECTED]> 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 JIRA blocker issue on this later today (after all the meetings are
over *whew*). I'll use the Title/Summary: Make DBO 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
behavior.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
