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

[Remi Forax]

On 09/03/2013 11:07 AM, Alan Bateman wrote:
> 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.

One fix that is very interresting IMO is to fix the way the stacktrace 
is created in Throwable.
It will not solve the world peace but in the same time it will speedup 
all programs that create a stacktrace,
not that bad too.

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

Rémi