A way to opt out of access restrictions on non-exported members.

[Remi Forax]

Reinier,
please answer to my mail, not to something i may have said.

My previous mail is not about security*, it's about stronger encapsulation.
To develop applications with several dozens of jars/modules, internal implementation details of a module should never leak outside of a module.

Rémi
* my mom told me to never use a 's' word. 

----- Mail original -----
> De: "Reinier Zwitserloot" <reinier at zwitserloot.com>
> À: "jigsaw-dev" <jigsaw-dev at openjdk.java.net>
> Envoyé: Lundi 16 Novembre 2015 14:21:15
> Objet: Re: A way to opt out of access restrictions on non-exported members.
> 
> 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
> .setAccessible.
> 
> *) 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
> either.
> 
>  --Reinier Zwitserloot
>