Mike Madrigaling 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 LIRA blocker issue on this later today (after all the
meetings are over *whew*). I'll use the Title/Summary: Make DO
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.
