Tom McQueeney <[EMAIL PROTECTED]> wrote on 19/04/2005 02:45:25 PM: > Bruce Snyder wrote: > > 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? > Correct, we don't currently allow remote access in the SystemDatabase configuration, but I think the current configuration isn't secure... Here is an excerpt of a mail titled "Securing the Derby Network Server in Geronimo - related to GERONIMO-342" I sent on 27 Jan 05: "Derby's DRDA (Distributed Relational Database Architecture) Network Server by default only listens for connections on the loopback address (which is a good default) and does not have authentication turned on. Therefore on a multiuser O/S this level of security seems inadequate as any user on the localhost could connect to it using the DB2 Universal Connector (specifying any userid and password as it will be ignored by the server) and start creating databases/tables etc. " > 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. +1 > > 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. I don't think we should prevent access completely from a remote client to the SystemDatasource, it could be useful to be able to connect to it for support/diagnostic purposes (especially when Geronimo is running on a headless server where you are limited to the tools you can use). It should definately be password protected and the Geronimo installation process should force the user to enter a password, so that we don't have thousands of Geronimos around the world running with default passwords. > > >>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. The following link seems to suggest that security can be used for the embedded database: http://incubator.apache.org/derby/manuals/develop/develop95.html#HDRSII-CSECUR-12392 > > 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. Sounds like it is worth discussing on the Derby mailing lists (if it hasn't already)? > > 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. Would be nice to have it integrated to simplify configuration for those new to Geronimo. Whatever solution we provide out of the box, should be quick to set up so the user can get started quickly (e.g. using properties files). Maybe down the track the installer could make it easier to install with more advanced types of authentication?? > > -Tom
