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

[David M. Lloyd]

It's simple enough to just create an accessor object and add a security 
check on creation.  There does not need to be a significant jam-up over 
this issue afaict.

On 09/03/2013 07:24 AM, Nick Williams wrote:
>
> On Sep 3, 2013, at 4: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.
>
> Well so much for being open.
>
>> However, as a general point then caller sensitive methods have been highly problematic in the JDK.
>
> If security issues aren't allowed to be discussed in the open then how can we, the community, help address them? You say my patch has security problems. I haven't seen any detailed yet.
>
>> 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'd argue that Logback, Log4j, and Groovy, three of the most common Java framework around, are very likely used with security managers quite often. It doesn't cause any problems because we don't misuse the information we obtain from getCallerClass.
>
>>>
>>> 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.
>
> We reached a point where a few people said the API looked good, and then someone said that hands were short and "patches are welcome." I was then given guidelines for submitting a patch. Doesn't sound like fizzling out to me.
>
>> 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.
>
> If applications want to change their behavior based on the caller, let them! Is it bad practice, bad design, and likely all kinds of dumb? Heck yea. But there are legitimate uses of this. Just because there are bad uses of this feature doesn't mean you must omit it. If that's the case, then we need to get rid of all input/output in Java--it could be used to write viruses to the file system! Oh, and we should remove Random, too, because applications might Randomly change their behavior! We must protect people from their own mistakes.
>
> One way the JVM uses getCallerClass, if I understand correctly, is to detect if the code executing a certain method is allowed to. Would you deny the same ability to applications written for the JVM? And, of course, logging frameworks are the obvious exception. Think of the performance improvements that could be had if, while determining the source of an event, loggers could get the exact one frame they needed (via StackTraceFrame#getCallerFrame, ~100ms per 1,000,000 calls) instead of having to generate an entire stack trace and loop through it to find the one frame (Thread#getStackTrace(), ~3,000ms per 1,000,000 calls).
>
>> I see Mandy has restarted the discussion on use-cases (thank you Mandy)
>
> Sounds like starting over to me.
>
>> 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.
>
> As I have said before, there are MANY ways to get a Class object that aren't security checked. It's when you try to USE that class object to impersonate it or invoke methods that security checks begin to happen. As they should!
>
> Nick
>


-- 
- DML