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 Tue, 28 Nov 2006 00:02:34 GMT
Rick Hillegas wrote:
> 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.

1c) Use Java Permissions, e.g.

org.apache.derby.security.DatabasePermission(String name)
target names
    create - allows databases to be created
    shutdown - allows database to be shutdown

Haven't thought it through a great deal, but utilizing an existing 
mechanism should be considered.

Dan.



Mime
View raw message