geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Should J2EE apps be using the SystemDatasource ?
Date Tue, 19 Apr 2005 08:16:58 GMT
Tom McQueeney <> wrote on 19/04/2005 02:45:25 PM:

> Bruce Snyder wrote:
> > On 4/18/05, <> wrote:
> > 
> >>Is the SystemDatasource only intended for the internal use of Geronimo 
> >>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 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.

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
> java
> >>
> >>ActiveMQ's table creation statements are in the 
> >>(..) method in
> 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:

> 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

View raw message