[
https://issues.apache.org/jira/browse/DERBY-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502988
]
Dag H. Wanvik commented on DERBY-2728:
--------------------------------------
> You even resolved the problem where simply specifying 'updgade=true'
> on the connection URL (when an upgrade was not needed: DB is already
> at version 10.3) blocked users other than the DBO from accessing the
> database.
Just to clarify this: even if an upgrade has already been performed,
supplying the upgrade flag if the user is *not* dbo, *and* both
properties (authentication and sqlAuthorization) are set, will still
throw an exception. It is just the conditions under which this
happens that have narrowed..
> 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.
