Rick Hillegas wrote:
When we introduce system-wide and database-specific privileges we will
need at least one more knob. This additional knob will control whether
these privileges are checked or whether legacy applications continue to
behave as they did in 10.2. Let us suppose this is another property.
Here are two ways to handle this knob:
3a) It could be boolean, that is, take true/false values just like
/derby.database.sqlAuthorization./
3b) Alternatively, it could be an integer, specifying the
privilege-checking level of the Derby engine.
Approach (3b) seems more flexible to me. It would allow us to add more
system/database privileges in future releases. Let's call this knob
/derby.system.privLevel/. It could behave as follows:
derby.system.privLevel unspecified (Default behavior. We don't check for
database or system privileges.)
derby.system.privLevel=10.2 (Default behavior above.)
derby.system.privLevel=10.3 (We check for the database and system
privileges introduced in 10.3.)
derby.system.privLevel=10.4 (We check for the database and system
privileges handled by the previous release as well as any new database
and system privileges introduced in 10.4.)
Please let me know what you think about this proposal and whether you
have other ideas about how to manage the upgrading of legacy
applications to 10.3.
I think more mode settings is not a good idea. I would view this as
closing security holes that make the existing SQL authorization mode
insecure. For all of these we can provide instructions on how to modify
10.2 applications to work in 10.3.
Dan.
