<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>From: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Emmanuel Bernard <<a href="mailto:emmanuel.bernard@jboss.com">emmanuel.bernard@jboss.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Date:<span class="Apple-converted-space"> </span></b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"> August 4, 2009 16:26:57<span class="Apple-converted-space"> </span>EDT</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>To: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><a href="mailto:jsr-303-eg@jcp.org">jsr-303-eg@jcp.org</a></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Subject: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><b>Re: [jsr-303-eg] [NEW] SecurityManager considerations</b></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Reply-To: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><a href="mailto:jsr-303-eg@jcp.org">jsr-303-eg@jcp.org</a></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> </div><div><br>On Aug 4, 2009, at 12:57, Ed Burns wrote:<br><br><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Thu, 16 Jul 2009 14:19:49 -0700, Ed Burns <<a href="mailto:Ed.Burns@Sun.COM">Ed.Burns@Sun.COM</a>> said:<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Wed, 15 Jul 2009 08:21:06 -0400, Emmanuel Bernard <<a href="mailto:emmanuel.bernard@jboss.com">emmanuel.bernard@jboss.com</a>> said:<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite">EB> Is there other specs enforcing that. I know JPA does not, I am<br></blockquote><blockquote type="cite">EB> wondering if other pluggable EE specs enforce such calls.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">EB> I'll ask around and report back.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">EB> Other question, what's the perf cost?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">EB> At the same time as discussing runtime performance cost, we also need to<br></blockquote><blockquote type="cite">EB> agree on how strongly we want to require it. My original wording<br></blockquote><blockquote type="cite">EB> started with, "If the implementation is intended to run in a container<br></blockquote><blockquote type="cite">EB> with the SecurityManager enabled..." meaning that compliance is<br></blockquote><blockquote type="cite">EB> optional. I think we should stick with that level of compliance.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">EB> As for runtime performance, I'll ask our expert but I think the general<br></blockquote><blockquote type="cite">EB> practice is to use the doPrivledeged() versions only if actually running<br></blockquote><blockquote type="cite">EB> with SecurityManager enabled.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Here's what Ron Monzillo had to say when asked this question.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Fri, 17 Jul 2009 10:28:37 -0400, Ron Monzillo <<a href="mailto:Ronald.Monzillo@Sun.COM">Ronald.Monzillo@Sun.COM</a>> said:<br></blockquote></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">RM> Ed, as I said, he should only wrap those apis, that having done so,<br></blockquote><blockquote type="cite">RM> woould not be such that they would then provided their callers with an<br></blockquote><blockquote type="cite">RM> opportunity to exploit the java security model. Iow, he doesn't want his<br></blockquote><blockquote type="cite">RM> api to be the manifestation of a capability that can be used by its<br></blockquote><blockquote type="cite">RM> callers to do things that they would otherwise be prevented (by the<br></blockquote><blockquote type="cite">RM> security managr from doing) from doing.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">RM> within that context, which I admit is pretty high level, the answer to<br></blockquote><blockquote type="cite">RM> his question afaik, is no, in other words I don't know of any places<br></blockquote><blockquote type="cite">RM> where we have mandated such encapsulation... but you can turn the<br></blockquote><blockquote type="cite">RM> question around, or at least reinforce what you have already said,<br></blockquote><blockquote type="cite">RM> perhaps by saying (somthing like)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">RM> if he doesn't do the encapsulation within his api, he is in establishing<br></blockquote><blockquote type="cite">RM> a requirement that the java protection model be disabled for any<br></blockquote><blockquote type="cite">RM> application that needs to call his api; which as you hav noted<br></blockquote><blockquote type="cite">RM> substantially limits the potential utility of running with a security<br></blockquote><blockquote type="cite">RM> manager enabled.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Please let me know if you need more information.<br></blockquote><br>Here is my analysis.<br>The RI does need to priviledge the following calls:<br> - Thread.getContextClassLoader()<br> - Class.getClassLoader()<br> - Class.getMethods()<br> - Class.newInstance()<br> - Class.getMethod(String)<br> - Class.getConstructor()<br> - Class.getDeclaredFields()<br> - Class.getDeclaredMethods()<br> - Class.getDeclaredField(String) / getDeclaredMethod(String)<br> - AccessibleObject.setAccessible<br><br>The RI might need to priviledge the following calls:<br> - method.invoke<br> - Field.get<br><br>Now here are the gotchas.<br>Bean Validation does expose some of the result of these methods (indirectly).<br> - ConstraintViolation.getInvalidValue does expose the value and a few of the priviledged info (property path, leafBean etc)<br> - the metadata API does expose property names (and their return type): there are the names of potentially non public field or getters<br><br>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.<br><br>So we have two choices, consider that if the user does not have access to these priviledges, we fail as well (the current impl).<br>Make use of our priviledged position but be aware of the leaks we enable.<br>WDYallThink?<br></div></blockquote></div><br></body></html>