Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)
Alan.Bateman at oracle.com
Wed Sep 28 12:01:28 UTC 2016
On 28/09/2016 10:37, Gunnar Morling wrote:
> I don't think that is what those folks asking about using the SM had
> in mind.
> Rather, the idea would be - IIUC - to grant code in module B (say an
> ORM tool) reflective access to non-exported (and of course exported)
> types in module A (say a module with entities) by default. If needed,
> the code in B would then use setAccessible() for making private
> members in A accessible before invoking them, allowing it to obtain
> the entity state. This is where the SM is part of the picture: if in a
> given environment the user wants to restrict who may call
> setAccessible(), they could use the SM for it, with a fine grained
> policy, e.g. allowing the call only to the ORM module.
> I.e. ReflectiveAccessToNonExportedTypes would be granted by default,
> only if an SM is enabled at runtime, actions to suppress accessibility
> checks would be subject to the current security policy.
> This is not to say that I'm behind this idea, I just felt it hasn't
> been discussed in the way it may have been meant.
> I can see though how JDK devs and library authors want to prevent
> access to private code in their modules at all, hence relying on the
> SM to be enabled at runtime is not an option to address that requirement.
The original question mentioned "reflective access" and we've said, has
always been specified to do the same access checks as the Java Language
On setAccessible, then it wouldn't be hard to have setAccessible
implement fine grain permission checks but not clear how useful this is
given that the SM is opt-in and not widely used. Having setAccessible
ignore module boundaries (assume no SM) goes against the goal of strong
encapsulation and of course makes #AwkwardStrongEncapsulation a lot worse.
In general then I think that we need to find ways to reduce the use of
setAccessible over time. We really need a long term plan to degrade,
deprecate and eventually remove it. This would of course mean working on
some challenging problems and use-cases.
So what would the alternative to setAccessible be? It would be nice if
the framework libraries (you mention ORM tools and maybe the Hibernate
ORM devs could be the guinea pig) would start to make use of the "new
reflection API" that is java.lang.invoke. So rather than bypassing
access checks with legacy core reflection then they would instead use
MH.Lookup objects as capabilities. Think code in a consumer module
creating a Lookup object with the appropriate lookup class + mode that
it cooperatively hands to the framework. This puts the access check in
the consumer module so that the frameworks don't need to break in. This
direction isn't without challenges of course as there may be
initialization issues to deal with. It might, for example, involve
injecting helper code into a submissive consumer module when there isn't
explicit initialization. John Rose has good write-ups in JIRA with ideas
in this area.
More information about the jigsaw-dev