geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (GERONIMO-305) JNDI local (intra cluster) access
Date Thu, 16 Sep 2004 23:31:37 GMT
The following comment has been added to this issue:

     Author: David Blevins
    Created: Thu, 16 Sep 2004 4:30 PM
We currently don't have this vulnerability as we do not have a global JNDI tree containing
DataSources, JMS destinations, or connection factories.  The only way to get one of those
is to have an EJB or Servlet with the required ref in its deployment descriptor.  

J2EE App Client support is being worked on at this very moment and the same rule applies;
you can only access what you declare in your deployment descriptor.

All components (EJB, Servlets, App Clients) have their own separate JNDI tree that is stored
in that component's container, not rooted in some master tree containing all JNDI trees. 
So no form of "Path" hacking is possible such as 'ctx.lookup("java:comp/env/../../../not/mine")'

The only things non-J2EE clients can access are the home/remote interfaces to EJBs.  Access
to anything else is not possible.

View this comment:

View the issue:

Here is an overview of the issue:
        Key: GERONIMO-305
    Summary: JNDI local (intra cluster) access
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Apache Geronimo

   Reporter: Ken Horn

    Created: Thu, 16 Sep 2004 3:31 PM
    Updated: Thu, 16 Sep 2004 4:30 PM

In order to protect JDBC datasource and JMS destinations / connection factories, that are
bound into the cluster JNDI tree, from j2ee client access, provide a mechanism to simply prevent

Note the points below relate to datastores, but they apply equally well to other objects like
authenticated JMS end-points -- secure JNDI access in general.

The request is to provide a mechanism to protect objects in jndi from being accessed from
outside the server(s) VM (obviously optional, but should be simple to enforce).

Here are some notes from a thread on the dev list (15 sept):

On Weblogic (WLS), the datastore on the default drivers is serializable (it's bound to the
clustered jndi, via a ClusterRemoteRef), and so a servlet / ejb /  client app can grab the
ds from jndi ( using JNDI Reference / ObjectFactory stuff). The ds reference in the client
can then create a direct db connection from the code to the db.

So key questions are:
* are datasources / JMS objects by default serializable (does Geronimo use something like
the wls remote ref or is the raw driver datastore used?)
* can client apps access the server jndi tree?
* if yes for the previous q, is there a way to bind an object that isn't remotely accessible?

Suggested implementations:
* a different jndi tree - perhaps a different context factory etc
* a fixed branch of the tree with is not exported / visible to out-of-process clients
* a naming convention
* WLS style local-only roles & run-as

Depending on the JNDI impl, any are ok -- the first is probably best, but most hassle for
users, while the next two are easier to use, but may be hacky to implement nicely (and raises
questions about being able to sandbox apps/areas to only see bits they want.. can of worms?).

The role based one seems more j2ee, but is a pain to configure since I think you need the
facade stuff mentioned earlier.

This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message