jdk.internal.reflect.ReflectionFactory and SecurityManager

[Paul Sandoz]

> 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?


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

Yes, moving it within that phase may anyway tickle a circularity for other reasons, we have been bitten before for different reasons when the java.util.secureRandomSeed property is set to true.

Paul.