> On 9 Jan 2017, at 05:36, Alan Bateman <alan.bate...@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.
