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".
