Vlada,
Vlada Matena wrote:
>
> The restrictions apply to the classes that are delivered as part of the
> enterprise bean code (i.e. to the classes in the ejb-jar file).
>
> The restrictions do not apply to the container implementation classes.
> The JDK classes are considered to be part of the container.
I've been reading this list from the beginning, but I have yet to fully
understand the restrictions imposed on JNI, threads, use of the I/O API
etc. The spec does not provide clear rationales for the restrictions (I
mean something more substantial than "this might create a security
hole") and does not discuss alternative strategies. As a result, the
same questions come back again and again on the list, with less than
satisfying answers like "use CORBA" or "wait for the Connectors API".
Let's take JNI as an example. Here is my attempt at a summary:
- loading a native library inside an EJB instance is a no-no, and the
container should typically intercept any attempt to do so through a
proper security policy (but a container provider may decide not to do
that);
- since loading a native library is "the responsibility of the
container" (as per the spec), one would expect that the container
provides the beans with the ability to request the loading of a native
library: I am not aware of any way to do this;
- loading a native library in a helper class packaged in the EJB-jar
file is also a no-no, because you just said so (I'm not sure if it's
clearly said in the spec);
- loading a native library from any code that is not packaged in the
EJB-jar file is therefore OK: this might be an RMI object living in the
same VM, an object retrieved from a JNDI tree, a JMS Message Consumer, a
servlet, whatever...
Is this last point really correct ? If it is, how exactly is that more
secure than loading the library directly in the EJB instance or a helper
class packaged in the EJB-jar file ? Supposing that the EJB retrieves a
serializable object from JNDI and this object loads a native library,
could/should the container restrict the behavior of this object ? What
about an RMI object that is living in the same VM but is outside of the
control of the EJB container ? Could you please clarify the rules ?
Thanks,
Alain.
--
Alain Rogister
Ubiquity s.a.
http://www.ubiquity.be
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
