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" <rein...@zwitserloot.com> > À: "jigsaw-dev" <jigsaw-dev@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 <fo...@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 >
