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
> EJB Container implementations are typically considered to be fully
> trusted.
>
> A container would typically bracket the implementation of all its
> component accessible methods with doPriviledged.
>
> There are no places that I'm aware of where the EJB spec requires
> container code to run with the priviledge restrictions of the component.
>
> So, the EJB requirement that components run with the minimum specified
> set of permissions should not result in overly complicated container
> implementations.
>
> -- Mark
>
> Alan Greenspan wrote:
> >
> > Implementing the EJB Security policy, as defined in the spec, leads to
some
> > interesting implementation issues. I'd be interested to know if anyone
as
> > observed these or similar problems.
> >
> > Basic issue surrounds the algorithm for checking permissions as
described in
> > the Java Security Architecture (section 4.2.1). A codebase is given the
> > MINIMUM subset of the Permissions granted specifically to it and the
> > Permissions granted to all its callers. The only way to get around this
is
> > to use doPrivileged blocks which ignore the Permissions associated with
the
> > callers and run the code with the exact permissions associated with its
> > codeBase.
> >
> > OK, so as for EJBs ... they run with extremely limited permissions, no
> > thread creation, no file I/O, etc. So anything an EJB calls is limited
in
> > like fashion unless that code is written using doPrivileged blocks.
One of
> > the problems we've seen is an EJB doing a JNDI lookup (happens to be
> > CosNaming provider), which calls down into the ORB, which tries to
create a
> > thread which then gets a security violation since the EJB doesn't have
> > permission to create a thread.
> >
> > So, what's the solution? You can hack around the problem with a custom
> > SecurityManager which allows the specific access to pass when it
normally
> > would not. But this is really not very satisfying.
> >
> > The bigger question is whether this security model is really workable.
> > Should code be written to use doPrivileged blocks or not? If you write
a
> > subsystem that needs certain permissions, it seems that you must use
> > doPrivileged blocks or risk getting Security violations. On the other
hand,
> > if you want to limit the accessibility of your code to that of your
clients,
> > you should not use doPrivileged. In general, this is a rather messy
> > situation.
> >
> > Seems to me that the Security Architecture should not by default have
such a
> > restrictive built in algorithm. Since the actual permissions are
granted
> > through the security policy and the policy is controlled by the
deployer,
> > you should be able to establish the required permissions via the policy
> > without need for such a restrictive algorithm.
> >
> > Attached is a backtrace, using the Sun JNDI CosNaming provider.
> >
>
------------------------------------------------------------------------
> > Name: backtrace
> > backtrace Type: unspecified type (application/octet-stream)
> > Encoding: quoted-printable
>
>
===========================================================================
> 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".
