db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2728) Make DBO restrictions from Derby-2264 optional for upgrades
Date Fri, 08 Jun 2007 02:41:26 GMT

    [ https://issues.apache.org/jira/browse/DERBY-2728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12502617
] 

Dag H. Wanvik commented on DERBY-2728:
--------------------------------------

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.

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

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message