On 4/18/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Is the SystemDatasource only intended for the internal use of Geronimo and associated components (e.g. Geronimo's "timertasks" table, ActiveMQ's tables ) and not intended for direct use by J2EE applications? I am guessing some reasons for this could be:
* safety - we don't want J2EE apps playing with our internal tables or have any table name conflicts with J2EE apps * performance?
There is another possible safety issue. From my understanding of the specs, JSR 151 J2EE.2.5 requires a JDBC database to be accessible from a client container. To me, that requires or implies a client application running on a remote machine must be able to access Derby. That means Derby must be configured to listen on an external network interface, or Geronimo needs to provide a JDBC listener to delegate to Derby.
Here are some thoughts. If I'm I'm off base or if these issues already have been addressed, please let me know.
o The SystemDatabase configuration sets up Derby to listen only on localhost. That means external client containers won't be able to access the JDBC database by connecting directly to Derby. Will this setup pass certification tests, or is another mechanism provided for remote J2EE clients to access the database?
o If Derby is set up to listen on 0.0.0.0 or the server's external interface, Derby should be set up to require authentication to close the security hole of any client being able to modify any Derby database.
o The Geronimo J2EE client container could be set up to provide a DataSource through JNDI that prohibits access to the SystemDatabase. That would provide some level of protection. But if Derby is listening on a public interface, requiring client authentication would still be a good idea.
Does anyone know of any other tables that will be placed in the SystemDatasource?
some notes for future reference...
Geronimo's "timertasks" table creation statements are in geronimo\modules\timer\src\java\org\apache\geronimo\timer\jdbc\JDBCWorkerPersistence.java
ActiveMQ's table creation statements are in the getCreateSchemaStatments (..) method in activemq\modules\core\src\java\org\activemq\store\jdbc\adapter\DefaultStatementProvider.java
I agree that we don't want J2EE apps messing with system related resources like the SystemDatasource, but I don't know that there is any manner in which to scope such resources only for use by the kernel or GBean-wrapped components. Is there any such feature?
Bruce
Derby provides three modes of user authentication: using an LDAP server, the "BUILTIN" user repository that uses system properties for usernames and passwords, or providing a custom "UserAuthenticator" class.
Once authentication is enabled, you can restrict access to Derby's SystemDatabase by setting the "defaultConnectionMode" property to "noAccess" or "readOnlyAccess" to limit what outsiders can do to the database. That would mean Geronimo needs to login to Derby as an authorized user, or (continue to use?) the embedded JDBC driver, which I think bypasses security.
One shortcoming with authorization: the current version of Derby allows all authenticated users to shutdown Derby if they connect from localhost. You don't need a special authorization level to shutdown the Derby network listener. This is not a certification issue, but it is an interesting security issue.
I think enabling Derby's user authentication system and restricting access to the SystemDatabase DB would be a good idea. Would it work to tie Derby in to Geronimo's existing user authentication system? If yes, perhaps someone can point me to the right classes/module and I'll take a stab at integrating it with a Derby UserAuthenticator.
-Tom
