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