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 Tue, 28 Nov 2006 14:42:49 GMT
Hi Dan,

Thanks for your responses. Some more comments follow inline...

Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Missing privileges specific to a particular database:
>> - Shutdown that Database
>> - Encrypt that database
>> - Upgrade database
> I assume that when in SQL authorization mode these three should, by 
> default, be limited to the database owner. I guess today with 10.2 
> there is no such limitation in place. If that restriction was 
> enforced, would there be any demand for the ability to grant the 
> permission to other users?
Right, I think that by default these powers should be restricted to the 
database owner. I also am having a hard time imagining why you would 
want more than one person wielding these powers at any one time. The 
only GRANT scenario I can think of, off the top of my head, would be 
transferring these powers to a successor when the dba moves on to 
another job. That case could probably be handled by telling users to set 
up a special dba account for managing the application.

Thanks for bringing up these issues. They suggest that GRANT/REVOKE 
might be overkill for authorizing these powers.
>> - Create (in that Database) Java Plugins (currently 
>> Functions/Procedures, but someday Aggregates and VTIs) 
> Can you explain what this means, what security issue are you trying to 
> address?
I'm concerned about being able to exploit security holes in code not 
supplied by Derby or the application. For instance, security holes in 
the jdk classes or in other applications hosted on the same vm.

> Dan.

View raw message