4 Replies Latest reply on Apr 24, 2003 7:15 AM by adrian.brock

Part 1: Unified Classloader

moraelin Apr 17, 2003 9:30 AM

Aside from just being a pain in the rear to use in a real production environment, the Unified Classloader is also not particularly standard conform.

E.g, section "21.6.9 Runtime security enforcement" states that: "The EJB Container must isolate an enterprise bean instance from other instances and other application components running on the server. The EJB Container must ensure that other enterprise bean instances and other application components are allowed to access an enterprise bean only via the enterprise bean’s component and home interfaces."

It doesn't even take much imagination to break this restriction once you have a classloader which sees all classes from all ear files on the server. E.g., you can instantiate the EJB implementation class or its DAO classes directly, via reflection.

It also feels a need to state again at the end of the next paragraph: "The EJB Container must ensure that the interactions between the enterprise beans and the container are only through the EJB architected interfaces."

Needless to say, interactions along the lines of "deploying bean B severely breaks bean A and servlet C, due to classloader conflicts" is not one of the EJB architected mechanisms.

1. Re: Part 1: Unified Classloader

bill.burke Apr 17, 2003 2:34 PM (in response to moraelin)

> Aside from just being a pain in the rear to use in a
> real production environment, the Unified Classloader
> is also not particularly standard conform.
>

Depends on the application. Sometimes its a pain, sometimes a godsend, which is why it is OPTIONAL!

classloading architecture/config I believe can be downloaded at http://sourceforge.net/projects/jboss/ under the downloads section.

> E.g, section "21.6.9 Runtime security enforcement"
> states that: "The EJB Container must isolate an
> enterprise bean instance from other instances and
> other application components running on the server.
> The EJB Container must ensure that other enterprise
> bean instances and other application components are
> allowed to access an enterprise bean only via the
> enterprise bean’s component and home
> interfaces."
>

Deployed EJBs can only be accessed through their home and remote interfaces. Don't know what you're talking about. Sure, you can access the static methods/fields.

> It doesn't even take much imagination to break this
> restriction once you have a classloader which sees
> all classes from all ear files on the server. E.g.,
> you can instantiate the EJB implementation class or
> its DAO classes directly, via reflection.
>

And why would you want to?

> It also feels a need to state again at the end of the
> next paragraph: "The EJB Container must ensure that
> the interactions between the enterprise beans and the
> container are only through the EJB architected
> interfaces."
>
> Needless to say, interactions along the lines of
> "deploying bean B severely breaks bean A and servlet
> C, due to classloader conflicts" is not one of the
> EJB architected mechanisms.

I don't know about WLS 6.0 and greater, but the classloading mechanism of WLS 5.x was even a more pain in the ass. We had ClassCast and LinkageErrors all the time because our Servlets and EJBs were passing around the same utility classes.

BUT AGAIN. UNIFIED CLASS LOADING IS OPTIONAL!
Actions
2. Re: Part 1: Unified Classloader

moraelin Apr 17, 2003 3:44 PM (in response to moraelin)

I'm not saying whether or not it's more useful or more optimal or "why would you want to" or whether WLS is even worse or whatever. I'm talking about whether it's standard conform or not. You asked for feedback about standards compliance, this is merely my feedback. Whether you actually do anything with it, well, that's no longer my problem.

Either way, it _is_ possible to instantiate someone else's EJB class directly. Not just access the static members, but actually create an instance and call its methods directly. Completely bypassing not only the Remote/Local and Home/LocalHome interfaces in the process, but also completely bypassing JAAS, completely bypassing any declared method/role restrictions, etc. Ditto for the JMX beans which make up JBoss itself. (Another thing that the specs state that I shouldn't be able to.)

Why would I want to? I don't know. Does it even matter? Is there actually a paragraph in the specs which says you're exempt from the "must" parts as long as noone wants to abuse that? :)

BTW, I'm looking at that site on sourceforge, and I'm not sure what to download from there. If you mean the .pdf file, sure, I've read it already, it didn't help: last time I tried disabling that as per the pdf manual (i.e., via jboss-app.xml), the beans suddenly couldn't call each other any more, if they were in different .ear files. Oops. Basically the cure was worse than the problem, so it didn't look that optional to me. Maybe there's another file somewhere around there which fixes that in a less dysfunctional way, but seein' as it's not obvious which one it is, I think you can't blame me for not knowing it even exists :)

If you could please point me to the exact file, I would really appreciate it.
Actions
3. Re: Part 1: Unified Classloader

davidjencks Apr 23, 2003 10:04 PM (in response to moraelin)

I'm no expert on java security, but I would like to know how it is possible to prevent say a stateless session bean from creating an instance of its implementation class.
Actions
4. Re: Part 1: Unified Classloader

adrian.brock Apr 24, 2003 7:15 AM (in response to moraelin)

Install a security manager.
Don't give the class the permission to do
classloading or reflection.

The UnifiedClassLoader doesn't break this,
what breaks it is that when jboss classes do this
they should run in doPriviledged blocks with
permissions for these operations.

The same is true of file access, binding server sockets,
thread operations, accessing system properties, using
the MBeanServer, etc.

Regards,
Adrian
Actions

Go to original post