[PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

[Alan Bateman]

On 02/09/2013 18:45, Nick Williams wrote:
> :
>
> I didn't decide to ignore the security concerns, I just don't see any security concerns. As has been /clearly/ established in the last three months, frameworks have been using getCallerClass for years, if not a decade. It has never caused a security problem. Ever. If I'm wrong, please point out to me a specific vulnerability that this has led to.
I am not allowed to discuss any details about vulnerabilities here. 
However, as a general point then caller sensitive methods have been 
highly problematic in the JDK.

As regards frameworks using sun.reflect.Reflection.getCallerClass 
directly then it's as I said previously, they are probably not run with 
a security manager very often (at least not unless the policy is 
configured to allow direct access to sun.*).

>
> I don't have the ability to go back and start from the beginning on something that I had the understanding was generally agreed upon before I started.
You've done good work and no one is suggesting you throw it again. 
However I don't recall any agreement on a solution, rather the 
discussion mostly fizzled out. In particular I do not recall any 
discussions about changing the goals of JEP 176 and make @CS a public 
API. Whatever about @CS methods being a bad there is also the issue of 
annotations changing runtime behavior.

I see Mandy has restarted the discussion on use-cases (thank you Mandy) 
and working through these and addressing a subset initially might be 
good way to move this forward. More so as this is your first 
patch/contribution to OpenJDK - a first patch does not have to solve 
world peace, starting out with smaller changes is good.

> :
>
> I'm not voicing any objection to any kind of security/permissions checks in these methods. Before I can pass judgement one way or another, I'd want to know 1) specifically what type of permissions check you are looking for, and 2) what you're looking to achieve with said permissions check.
I would say this is TBD and start by asking the question as to whether 
there are concerns about leaking reference to Class objects that 
untrusted code wouldn't normally be able to get a reference to. Tom 
brings up the cost of the permission check and also whether any API 
should be tied to class loader. There are clearly discussion points here 
that could potentially influence the API.

-Alan.