Derby
  1. Derby
  2. DERBY-2728

Make DBO restrictions from Derby-2264 optional for upgrades

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 10.3.1.4
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Urgency:
      Blocker

      Description

      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 <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:
      >
      > 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 <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 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.

        Issue Links

          Activity

          Stan Bradbury created issue -
          Dag H. Wanvik made changes -
          Field Original Value New Value
          Link This issue is related to DERBY-2264 [ DERBY-2264 ]
          Stan Bradbury made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Closed [ 6 ]
          Kathey Marsden made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Kathey Marsden made changes -
          Status Reopened [ 4 ] Resolved [ 5 ]
          Resolution Duplicate [ 3 ]
          Kathey Marsden made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12405123 ] Default workflow, editable Closed status [ 12798481 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Stan Bradbury
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development