geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom McQueeney <...@mcqueeney.com>
Subject Re: Should J2EE apps be using the SystemDatasource ?
Date Tue, 19 Apr 2005 04:45:25 GMT
Bruce Snyder wrote:
> On 4/18/05, sissonj@insession.com <sissonj@insession.com> 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

Mime
View raw message