On Aug 4, 2009, at 12:57, Ed Burns wrote:
On Thu, 16 Jul 2009 14:19:49 -0700, Ed Burns <Ed.Burns@Sun.COM> said:
On Wed, 15 Jul 2009 08:21:06 -0400, Emmanuel Bernard <emmanuel.bernard@jboss.com> said:
EB> Is there other specs enforcing that. I know JPA does not, I am
EB> wondering if other pluggable EE specs enforce such calls.
EB> I'll ask around and report back.
EB> Other question, what's the perf cost?
EB> At the same time as discussing runtime performance cost, we also need to
EB> agree on how strongly we want to require it. My original wording
EB> started with, "If the implementation is intended to run in a container
EB> with the SecurityManager enabled..." meaning that compliance is
EB> optional. I think we should stick with that level of compliance.
EB> As for runtime performance, I'll ask our expert but I think the general
EB> practice is to use the doPrivledeged() versions only if actually running
EB> with SecurityManager enabled.
Here's what Ron Monzillo had to say when asked this question.
On Fri, 17 Jul 2009 10:28:37 -0400, Ron Monzillo <Ronald.Monzillo@Sun.COM> said:
RM> Ed, as I said, he should only wrap those apis, that having done so,
RM> woould not be such that they would then provided their callers with an
RM> opportunity to exploit the java security model. Iow, he doesn't want his
RM> api to be the manifestation of a capability that can be used by its
RM> callers to do things that they would otherwise be prevented (by the
RM> security managr from doing) from doing.
RM> within that context, which I admit is pretty high level, the answer to
RM> his question afaik, is no, in other words I don't know of any places
RM> where we have mandated such encapsulation... but you can turn the
RM> question around, or at least reinforce what you have already said,
RM> perhaps by saying (somthing like)
RM> if he doesn't do the encapsulation within his api, he is in establishing
RM> a requirement that the java protection model be disabled for any
RM> application that needs to call his api; which as you hav noted
RM> substantially limits the potential utility of running with a security
RM> manager enabled.
Please let me know if you need more information.
Here is my analysis.
The RI does need to priviledge the following calls:
- Thread.getContextClassLoader()
- Class.getClassLoader()
- Class.getMethods()
- Class.newInstance()
- Class.getMethod(String)
- Class.getConstructor()
- Class.getDeclaredFields()
- Class.getDeclaredMethods()
- Class.getDeclaredField(String) / getDeclaredMethod(String)
- AccessibleObject.setAccessible
The RI might need to priviledge the following calls:
- method.invoke
- Field.get
Now here are the gotchas.
Bean Validation does expose some of the result of these methods (indirectly).
- ConstraintViolation.getInvalidValue does expose the value and a few of the priviledged info (property path, leafBean etc)
- the metadata API does expose property names (and their return type): there are the names of potentially non public field or getters
Do we consider the exposition of these extra info as breaking the doPriviledge contract. As Ron was saying we are giving away some information that a non privileged code could not have access to otherwise.
So we have two choices, consider that if the user does not have access to these priviledges, we fail as well (the current impl).
Make use of our priviledged position but be aware of the leaks we enable.
WDYallThink?