db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: plugging more security holes in Derby
Date Wed, 22 Nov 2006 22:32:42 GMT
I would like to continue the discussion about how we can tighten up 
Derby system privileges for the client/server case. I would appreciate 
the community's feedback.

Here's where the discussion stands. We can imagine two big groupings of 
non-ANSI privileges not currently handled by our GRANT/REVOKE machinery:

1) System-wide privileges (e.g., Create Database, Boot all Databases, 
Shutdown System)

2) Per-database privileges (e.g., Shutdown Database, Encrypt Database, 
Create Java Plugins)

What I would like to brainstorm now is this: how should we control these 
privileges? Here are some thoughts:

1) How to control system-wide privileges

1a) We could invent the concept of a Master Database. For the moment, 
let's be vague about who creates this database and when. In this Master 
Database, we could use GRANT/REVOKE to manage system-wide privileges.

1b) Alternatively, we could supply a Java interface (and default 
implementation) for managing system-wide privileges. This is how Derby 
manages users. Right now, for managing users we supply an interface, 
org.apache.derby.authentication.UserAuthenticator with a default 
implementation which the customer can override. For the moment, let's be 
vague about what we would put in this interface.

I tend to think that (1a) is heavyweight while (1b) is more flexible. 
What do other people think? What other suggestions do people have for 
managing system-wide privileges?

2) How to control database-wide privileges

2a) We could use GRANT/REVOKE to manage database-wide privileges.

2b) This is (2a) with a twist: One of the database-wide privileges 
(Create Java Plugin) could be modelled as a per-schema privilege.

Other databases GRANT and REVOKE database-wide privileges. This, 
however, extends the ANSI spec in vendor-specific ways. Is that OK for 
Derby to do? In addition, DB2, Oracle, and Postgres scope the Create 
Java Plugin privilege at the database rather than the schema level. For 
these reasons, I think that (2a) would be fine. What do other people 
think? What other suggestions do people have for managing database-wide 

Thanks for your feedback. Please don't be offended if I don't reply 
until next week--I'm going on Thanksgiving holiday soon.


View raw message