EJB 1.1 and J2EE specs both require that components be restricted to the
minimum specified permissions.
How it is dealt with in container implementations and in J2EE code
provided by Sun (such as JNDI, JavaMail, CosNaming, RMI-IIOP, etc.) is a
useful topic to discuss. If there are things container developers would
like to see handled in Sun provided code we would like the feedback.
Please send it to the appropriate spec comment alias.
This requirement has gone through a long and thorough review process as
part of J2EE. There are many J2EE implementations in process including
the J2EE reference implementation which have effectively handled this
requirement.
At this point, it is highly unlikely that any change to this requirement
will be made.
-- Mark
Larry Allen wrote:
>
> Alan Greenspan wrote:
> >
> > If I follow what you are saying, the EJB Container must interpose on EVERY
> > Bean access to anything outside of itself and wrap the call with a
> > doPrivileged block - this means every JNDI call, every JDBC call, JMS call,
> > JTA call, ... EVEN every access to any remote object (i.e. another EJB).
> > The last case is a real killer - I don't see doPrivileged blocks in the RMI
> > stubs from Sun (JRMP or IIOP). The case we hit was in Sun's ORB on a JNDI
> > lookup, but could have just as easily been hit on any ordinary remote object
> > reference.
> >
> > It seems a bit much to insist that the container interpose on all references
> > to all enterprise Java APIs just to increase the privilege level. And in
> > some cases, we may not have the opportunity to interpose (e.g. in the case
> > of stubs, unless the Container vendor is also the RMI vendor or supplies its
> > own RMI stub generator).
> >
> > Someone at Sun should revisit the code base security model and consider
> > allowing a policy option in which a codebase gets the privileges it was
> > assigned regardless of who called it. Given that the deployer is in control
> > of setting the policy, this seems very reasonable, and it would obviate the
> > need for the container to wrap every EJB external access in a doPrivileged
> > block.
> >
> > Alan
>
> I agree with Alan on this one. We did the same analysis he did, of wrapping
> all EJB-callable methods with doPrivileged() blocks, and concluded that
> it was both prohibitively expensive and impossible -- not least because
> many of the EJB-callable methods were on classes implementing (e.g.)
> java.sql.Statement provided by 3rd-party JDBC driver manufacturers. Note
> also that every call to a doPrivileged() block typically involves use of
> an inner class, which introduces hundreds or thousands of additional
> classes to be loaded and managed. The approach quickly became impractical.
> I also agree with Alan's proposed solution, although it needs to be
> reviewed carefully for security loopholes.
> -Larry Allen
> SilverStream Software
>
> ===========================================================================
> 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".
===========================================================================
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".
