db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering" <da...@vancouvering.com>
Subject Re: 10.3 blocker issue - DERBY-2728
Date Wed, 30 May 2007 20:26:05 GMT
+1 to option 3.  What's crucial to me is that someone who is running
in a very secure environment or who doesn't care about the security of
the database (e.g. during development) does not have to deal with this
usability overhead.  Good to have for production, but keep it out of
the way for development and other "I don't care about security
"environments.

If someone has already taken the time to enable SqlAuthorization and
created the DBO role, then it's very likely they're in an environment
where they care about security and will probably like this added
security, even if it impacts compatibility.

We do have to keep a very close eye on compatibility, as many of the
use cases I am seeing has Derby embedded in some application
distributed across a wide array of machines where the user doesn't
know and doesn't want to know there is a database in there somewhere.

Thanks,

David

On 5/30/07, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> Myrna van Lunteren wrote:
> > Hi,
> >
> > We have a bump in our 10.3 release path - DERBY-2728.
> >
> > I'd like the opinion of the community as to how we can address this;
> > how long would a fix take (and thus delay a release); who would be
> > willing to implement a fix?
> >
> > Should we make a release candidate while the fixing is in progress?
> Hi Myrna,
>
> I think we need to agree on a solution first. I don't think you can
> create a release branch (or candidate) until we know whether we're going
> to call the release 10.3 or 11.0.
> >
> > Please give your 2 (or other #) cents.
> >
> > Regards,
> > Myrna
> It appears to me that three solutions have been proposed:
>
> 1) Call the release 11.0 rather than 10.3. That is, accept the
> incompatibilities.
>
> 2) Add an extra security knob. The default setting would be the old 10.2
> behavior.
>
> 3) Only restrict upgrade/encrypt/shutdown powers to the DBO if both
> authorization and authentication are turned on. This does not eliminate
> the incompatibilities but should greatly reduce the number of affected
> customers.
>
> My vote is for option (3).
>
> Regards,
> -Rick
>

Mime
View raw message