db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: plugging more security holes in Derby
Date Thu, 30 Nov 2006 00:17:42 GMT
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.


View raw message