You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Stanley Bradbury <St...@gmail.com> on 2007/05/26 01:46:28 UTC
10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
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 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?
- Stan
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by Stanley Bradbury <St...@gmail.com>.
Mike Madrigaling wrote:
>
>
> Dag H. Wanvik wrote:
>> Hi,
>>
>> Stanley Bradbury <St...@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 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.
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Dag H. Wanvik wrote:
> Hi,
>
> Stanley Bradbury <St...@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?
>
>
>
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
David Van Couvering <da...@vancouvering.com> writes:
> I thought that for most folks, authentication is turned OFF. I also
> thought that the default for Derby is to have authentication turned
> off. If this is not the case, then I think we have a real issue here.
> Also, are we going to change it so that authentication is on by
> default?
The default is still off, no change there.
Dag
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional at upgrade
Posted by David Van Couvering <da...@vancouvering.com>.
When we discussed this previously, I had asked Rick to take this to
the users, and he did, see:
http://www.nabble.com/Naming-the-next-Derby-feature-release-tf3329320.html#a9257363
I thought that for most folks, authentication is turned OFF. I also
thought that the default for Derby is to have authentication turned
off. If this is not the case, then I think we have a real issue here.
Also, are we going to change it so that authentication is on by
default? If that's true and you also can't shut down the database
without DBO authority, then I think this may be a bigger issue than I
had thought.
The question is, if a large subset of the community are going to
experience some kind of impact by this change, then we should think
very carefully before we break their existing apps.
Also, the message Rick sent out was entitled "Naming the next Derby
Release," and thinking about it now I don't believe caught enough
people's attention. Perhaps a re-send might make sense given this
debate...
David
On 5/29/07, Rick Hillegas <Ri...@sun.com> wrote:
> Daniel John Debrunner wrote:
> > Dag H. Wanvik wrote:
> >> Hi,
> >>
> >> Stanley Bradbury <St...@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
>
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Rick Hillegas wrote (2007-05-30 06:26:08):
> Bernt M. Johnsen wrote:
> >>>>>>>>>>>>>Ståle Deraas wrote (2007-05-30 08:23:05):
> >>>>>>>>>>>>>
> >>Maybe the thread "Q: Should Derby 10.3 be Derby 11?" raised by Bernt is
> >>what people are thinking of......
> >>
> >
> >The thread is here:
> >http://www.nabble.com/Q:-Should-Derby-10.3-be-Derby-11--tf3260195.html
> >
> >
> I have reviewed this email thread. It is largely a discussion about how
> compatibility issues affect release names. It includes some discussion
> about the secure-server work (DERBY-2196). It does not have much to say
> about DERBY-2264.
That's right. My question was raised based on the fact that my db
start script suddenly needed a -noSecurityManager switch in
10.3. I.e. an incompatability.
Stan is pointing at another incompatability, but in principle it's the
same kind of problem: 10.3 will not be compatible with 10.2.
> The discussion motivated us to document the
> incompatibilities introduced by DERBY-2196 and DERBY-2264--we described
> those incompatibilities at the end of the 10.3 release page:
> http://wiki.apache.org/db-derby/DerbyTenThreeRelease
>
> I don't see much discussion of DBO powers here.
>
> Regards,
> -Rick
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by Rick Hillegas <Ri...@Sun.COM>.
Bernt M. Johnsen wrote:
>>>>>>>>>>>>> Ståle Deraas wrote (2007-05-30 08:23:05):
>>>>>>>>>>>>>
>> Maybe the thread "Q: Should Derby 10.3 be Derby 11?" raised by Bernt is
>> what people are thinking of......
>>
>
> The thread is here:
> http://www.nabble.com/Q:-Should-Derby-10.3-be-Derby-11--tf3260195.html
>
>
I have reviewed this email thread. It is largely a discussion about how
compatibility issues affect release names. It includes some discussion
about the secure-server work (DERBY-2196). It does not have much to say
about DERBY-2264. The discussion motivated us to document the
incompatibilities introduced by DERBY-2196 and DERBY-2264--we described
those incompatibilities at the end of the 10.3 release page:
http://wiki.apache.org/db-derby/DerbyTenThreeRelease
I don't see much discussion of DBO powers here.
Regards,
-Rick
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by "Bernt M. Johnsen" <Be...@Sun.COM>.
>>>>>>>>>>>> Ståle Deraas wrote (2007-05-30 08:23:05):
> Maybe the thread "Q: Should Derby 10.3 be Derby 11?" raised by Bernt is
> what people are thinking of......
The thread is here:
http://www.nabble.com/Q:-Should-Derby-10.3-be-Derby-11--tf3260195.html
--
Bernt Marius Johnsen, Database Technology Group,
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by Ståle Deraas <St...@Sun.COM>.
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Dag H. Wanvik wrote:
>>> Hi,
>>>
>>> Stanley Bradbury <St...@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.
>
Maybe the thread "Q: Should Derby 10.3 be Derby 11?" raised by Bernt is
what people are thinking of......
/Ståle
> Regards,
> -Rick
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by Rick Hillegas <Ri...@Sun.COM>.
Daniel John Debrunner wrote:
> Dag H. Wanvik wrote:
>> Hi,
>>
>> Stanley Bradbury <St...@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
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by Daniel John Debrunner <dj...@apache.org>.
Dag H. Wanvik wrote:
> Hi,
>
> Stanley Bradbury <St...@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.
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Kathey Marsden <km...@sbcglobal.net> writes:
> I vote for this one. Default off for embedded. I am sorry I did not
> look closely enough at this one and consider the scope of impact. If
> database shutdown for every deployed embedded database in the world
> has to be the database owner, I fear it would have a large impact. I
Just to be clear, only databases for which authentication is turned on
are potentially impacted:
http://wiki.apache.org/db-derby/DerbyTenThreeRelease#head-39d10a9c64273423f141a7d0e6d1d66b01d491df
That may still be a significant portion...
Dag
> think it would be ok for the default to be on for network server if
> it is possible to differentiate.
>
> Kathey
>
>
>
>
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dag H. Wanvik wrote:
> - 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)
>
I vote for this one. Default off for embedded. I am sorry I did not
look closely enough at this one and consider the scope of impact. If
database shutdown for every deployed embedded database in the world has
to be the database owner, I fear it would have a large impact. I think
it would be ok for the default to be on for network server if it is
possible to differentiate.
Kathey
Re: 10.3 Concern: Need to make DBO restrictions [Derby-2264] optional
at upgrade
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
Hi,
Stanley Bradbury <St...@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?
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?