A way to opt out of access restrictions on non-exported members.
reinier at zwitserloot.com
Mon Nov 16 13:21:15 UTC 2015
Security hardening? The security manager already stops .setAccessible() if
you want it to, and if you don't stop that, you have no security anyway, so
there's no point. I do not understand the argument of '... blocking
.setAccessible() from letting you access members from non-exported packages
is better for security' at all.
With some more depth:
On Sun, Nov 15, 2015 at 7:14 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> - put all your modules in the classpath or remove all the module-info from
> the modules in the module-path,
> - create a jlink plugin that will crawle all modules (or the ones you
> want) and change the module-info,
> - at runtime to create a new layer that will bypass the application
> classloader and change the module configuration on-the-fly.
> And there are more exotic ways if you are able to change the bytecodes.
Exactly. Exotic ways. These options sounds sufficiently user hostile that
it'll slow JDK9 adoption significantly. A lot of them also don't sound like
something that team jigsaw would want. For example, if most java
deployments start dumping all the modules on the CP to get around this
issue, then... what was the point of the module system in the first place?
I'm trying to make the point: This COULD lead to the community en masse
establishing some hacky workaround as 'the new normal' because libraries
simply do not have the tools to become JDK9 ready in time (or ever). That
sounds like something to be avoided.
I don't understand the security element at all. The only way to cause
security issues if .setAccessible() would let you break through exports
requirements, is if untrusted code is allowed to run, in-process, on your
own JVM in the first place*. There is NO WAY to have such code (untrusted,
running in-process) be in any way or form safe unless a security manager is
involved, and the security manager is _already_ set up to allow you to deny
*) Technically, you could have code that calls .setAccessible(true) on an
element that is found based on untrusted user input, but this sounds like a
very exotic case, is already a security nightmare both in JDK8 and even in
a fully modularized JDK9 world; if we take as written that accessing any
element of a non-exported package is a huge security leak, how is accessing
private members of exported packages perfectly fine? That makes no sense
More information about the jigsaw-dev