I'm sure I'm missing something, but all your proposals sound pretty good to me on the face of it.
David > Thanks to Dan and Dag, I believe that Derby system privileges are > beginning to look much simpler. I would like to continue the discussion > about how we can plug more security holes in our client/server > configuration. So far we have discussed the following: > > 1) System-wide privileges (shutdown system, shutdown all databases, > create databases). > > 2) Database-specific privileges (shutdown, encrypt, upgrade, create > plugins). > > I would like to add another topic to the discussion: > > 3) Knobs. What kind of knobs do we need to control default behavior and > make upgrade smooth? > > Here then are some more thoughts: > > ------------ 1) System-wide Privileges ---------------------- > > The alternatives so far: > > 1a) GRANT/REVOKE in a master database > 1b) A user-implementable api modelled on > org.apache.derby.authentication.UserAuthenticator > 1c) Java permissions > > Some comparisons: > > (1a) > + Familiar api > - Non-standard extensions to that api > - Heavyweight > > (1b) > + Flexible > + Easy to extend > + Master database (something like (1a)) could be added as a special > implementation > + Modelled on an existing Derby api > > (1c) > + Standard mechanism > + Simple administration > + Easy to extend > - Requires that the whole VM runs under a SecurityManager > > I don't feel that it would be too onerous to require a SecurityManager > for the whole VM. I prefer (1c) over the other approaches because it is > a standard mechanism. > > ------------ 2) Database-specific Privileges ---------------------- > > The alternatives so far: > > 2a) GRANT/REVOKE extensions > 2b) Limiting privileges to the database owner > > Some comparisons: > > (2a) > + Familiar mechanism > - Heavyweight overkill for most of the privileges > > (2b) > + Simple > + Adequate for most of the privileges > - Perhaps overly restrictive for Plugin privilege > - How to migrate database ownership if DBA kicked upstairs to be CTO > > I prefer (2b) because it is simple. I think we could address its issues > as follows: > > i) Treat the Plugin power as a system-wide privilege rather than a > database-specific privilege. Manage Plugin power using Java permissions > per (1c). > > ii) We could add a warning paragraph to the security section of the > Developer's Guide. This paragraph would advise client/server users to > create special dba accounts for their databases so that they can migrate > database powers to a new dba when the old dba moves on to new > responsibilities. If this situation turns out to be a problem, a > follow-on release could introduce some mechanism for migrating the > ownership of databases. > > ------------ 3) Knobs ---------------------- > > In 10.2 we introduced a new knob, a property called > /derby.database.sqlAuthorization/. Its default setting (false) preserves > legacy Derby behavior, i.e., permissions are not GRANTed and existing > client/server applications continue to function in the old, insecure way > that is appropriate for embedded applications. Setting this property to > true enables permissions checking. > > 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. > > Thanks, > -Rick > >
