jdk.internal.reflect.ReflectionFactory and SecurityManager

[Alan Bateman]

On 09/01/2017 19:09, Paul Sandoz wrote:
>> On 9 Jan 2017, at 05:36, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>
>> On 05/01/2017 19:01, Paul Sandoz wrote:
>>
>>> Hi,
>>>
>>> I encountered some circularity issues with security manager and VarHandles, specifically when attempting to use the new MethodHandles.privateLookupIn, so say ThreadLocalRandom has access to fields in Thread [1].
>>>
>>> When running with a security manager ThreadLocalRandom clinit depends on various security stuff that eventually depends on ConcurrentSkipListMap which depends on ThreadLocalRandom, whose static state has not been fully initialzed.
>>>
>>> The current security permission check in MethodHandles.privateLookupIn may be a too blunt and possibly should be refined along similar lines to Lookup.checkSecurityManager e.g. no check should be needed for classes within the same module (since this is a refined/controlled/principled form of setAccessible, plus no pounding on final fields). That would solve the problem in this case. But, the general point remains, and i have not thought too hard if there are other ways to solve this.
>>>
>> This would mean inconsistency with setAccessible where you need this blunt permission when suppressing access. Also I think Lookup.checkSecurityManager will do different checks when you don't have a full power lookup so it would mean adjusting the privateLookupIn.
> Some adjustment would definitely be required, the perhaps the simplest solution is not to perform a security check if within the same module?
>
It might be okay when the lookup is a full-power lookup to class in 
java.base and it's called to get a full-power look to some other class 
in java.base. However, generalizing this would probably need security 
eyes. Consider two libraries on the class path (same unnamed module) for 
example. Also the inconsistency with setAccessible where it always 
checks the permission when running with a security manager.

-Alan