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?




Reply via email to