+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 <[EMAIL PROTECTED]> 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
