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

          Hide
          Daniel John Debrunner added a comment -

          Not sure what is being proposed here, the incompatibility is an issue regardless of upgrade.

          An existing application that creates databases will hit the incompatibility as well as one that upgrades.

          Show
          Daniel John Debrunner added a comment - Not sure what is being proposed here, the incompatibility is an issue regardless of upgrade. An existing application that creates databases will hit the incompatibility as well as one that upgrades.
          Hide
          Dag H. Wanvik added a comment -

          I just uploaded a patch on DERBY-2264 which
          restricts dbo powers enforcement to the case where
          both authentication and SQLAuthorization is enabled, regardless of
          upgrade state, cf recent discussions on derby-dev:

          http://www.nabble.com/10.3-blocker-issue---DERBY-2728-tf3838052.html
          http://www.nabble.com/10.3-Concern%3A-Need-to-make-DBO-restrictions--Derby-2264--optional-at-upgrade-tf3818844.html

          If committed, it may or may not be sufficient to solve the concerns raised
          in this issue.

          Show
          Dag H. Wanvik added a comment - I just uploaded a patch on DERBY-2264 which restricts dbo powers enforcement to the case where both authentication and SQLAuthorization is enabled, regardless of upgrade state, cf recent discussions on derby-dev: http://www.nabble.com/10.3-blocker-issue---DERBY-2728-tf3838052.html http://www.nabble.com/10.3-Concern%3A-Need-to-make-DBO-restrictions--Derby-2264--optional-at-upgrade-tf3818844.html If committed, it may or may not be sufficient to solve the concerns raised in this issue.
          Hide
          Dag H. Wanvik added a comment -

          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.

          Show
          Dag H. Wanvik added a comment - 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.
          Hide
          Stan Bradbury added a comment -

          Thanks Dag !!

          I applied DERBY-2264-9.diff to my sandbox and preformed some rudimentary upgrage tests to 10.1 and the issues I originally reported in this JIRA are resolved. 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. Thanks again for your timely reponse on this issue.

          Show
          Stan Bradbury added a comment - Thanks Dag !! I applied DERBY-2264 -9.diff to my sandbox and preformed some rudimentary upgrage tests to 10.1 and the issues I originally reported in this JIRA are resolved. 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. Thanks again for your timely reponse on this issue.
          Hide
          Stan Bradbury added a comment -

          The patch DAG supplied as part of the original DBO restrictions implementation has resolved this issue (assuming it will be committed soon).

          Show
          Stan Bradbury added a comment - The patch DAG supplied as part of the original DBO restrictions implementation has resolved this issue (assuming it will be committed soon).
          Hide
          Dag H. Wanvik added a comment -

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

          Show
          Dag H. Wanvik added a comment - > 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..
          Hide
          Stan Bradbury added a comment -

          Thanks for the clarification Dag. This will not be a problem for the situations I am concerned with. The biggest problem I saw was for systems that had did not use sqlAuthentication so had not established a DBO account and did not want to. Some implementations assign a single, shared username and password per schema so the connection will default to a specific schema. This is in addition to providing some security to the system, though shared accounts are known to be a security no-no.

          Show
          Stan Bradbury added a comment - Thanks for the clarification Dag. This will not be a problem for the situations I am concerned with. The biggest problem I saw was for systems that had did not use sqlAuthentication so had not established a DBO account and did not want to. Some implementations assign a single, shared username and password per schema so the connection will default to a specific schema. This is in addition to providing some security to the system, though shared accounts are known to be a security no-no.
          Hide
          Kathey Marsden added a comment -

          Duplicate of DERBY-2264

          Show
          Kathey Marsden added a comment - Duplicate of DERBY-2264

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development