jdk.internal.reflect.ReflectionFactory and SecurityManager

[Alan Bateman]

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.

I wonder if we could trigger more of this initialization in initPhase3 
before the security manager is set. I'm sure TLR::current will do but 
that might be too much to do at startup.

-Alan