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
