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

[Remi Forax]

On 09/02/2013 03:56 PM, Tom Hawtin wrote:
> On 02/09/2013 09:33, Alan Bateman wrote:
>
>>  From a quick scan then it appears that you've decided to ignore the
>> security concerns so I don't think anyone can (or should) sponsor this
>> patch until there is further discussion on the API and the security
>> implications.
>
> I've barely looked through the patch, let alone audited it. However:
>
> As the method appears to be mostly for tracing, performing a security 
> check per invocation is likely to hurt performance. Unless it was 
> caller sensitive (which seems to be equated with Bad Practice these 
> days) it would also require a doPrivileged block. Much better to 
> perform a single security check when acquiring a capability object, in 
> a similar(ish) way to sun.misc.Unsafe or SharedSecrets.
>
> In order to work with less privileged code, it may also be worthwhile 
> to provide a version of the capability object parameterised with a 
> class loader. If code has access to a ClassLoader object, then it is 
> consistent for it to be given access to Classes loaded by it or child 
> loaders, and in practice from parent loaders (but not children of 
> parents).
>
> Security relating to Class objects is "interesting". The genuine 
> security issue with Class objects is that they have are an attenuation 
> of the capability of their ClassLoader. There are many ways to acquire 
> Class objects. Some have confusing defence-in-depth security; some, 
> such as Object.getClass used for quick null checks, do not.
>
> Tom

I wonder if a java.lang.invoke.MethodHandles.Lookup is not a better 
object than a ClassLoader for a capability object.

Rémi