On 09/01/2017 19:09, Paul Sandoz wrote:
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?
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
