[
https://issues.apache.org/jira/browse/DERBY-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502617
]
Dag H. Wanvik commented on DERBY-2728:
--------------------------------------
I think the recently added modifications in DERBY-2264-9 address the changes
requested by this
issue (granted; that is only my intepretation of the original thread
discussions leading to this issue).
It would be nice if the reporter this out, and, if this is indeed the case,
close this issue.
I chose to make the required modifications as part of the original issue, to
keep the code changes in the same patch
as the releaseNote.html which describes the changes.
If more/other changes are intended by the reporter, it would be good to specify
here what further changes are
requested by this issue.
> 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.
