Thoughts on adding getElementClass() method to StackTraceElement? (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Sun Jun 16 16:42:36 UTC 2013

On 16/06/2013 15:29, Nick Williams wrote:

On Jun 16, 2013, at 1:25 AM, Jeroen Frijters wrote:

: SecurityManager.getClassContext() is not available to unpriviliged callers, so I don't think this a valid argument. Can you define what "is not available to unprivileged callers" means a little better? We use it in Log4j 2 when getCallerClass() isn't available, and it works just fine. I took a look at the Java code, and it's native, so there's no check there. (You can't instantiate a SecurityManager unless there's not currently a SecurityManager installed OR the installed SecurityManager allows the creation (installation privilege isn't checked) of another SecurityManager. Is that what you're talking about?) I took a look at the native code, and I don't see anything there that would represent a privilege check that I recognized, but if I understood what you meant a little better I might see where I'm wrong. The main thing is that the hack to extend SecurityManager (so that you can call the protected getClassContext method) is unlikely to work when there is security manager set. I can't tell what environments you have tested with but usually it means setting up the security policy so that the code base of your library is granted the permission. Even then you might still have an issue because there will likely be frames associated with other untrusted code on the stack. Maybe your code attempts to create the security manager does do with so privileges enabled, therwise everything that could potentially call you would also needed to be granted this permission.

-Alan.

More information about the core-libs-dev mailing list