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
