Revisiting encapsulation requirement

[Remi Forax]

Hi David,
I don't think we should modify the "encapsulation" requirement if the requirement
only apply to regular Java code and not on reflection + setAccessible(true).

Currently, when you use reflection, you have the same security checks as in plain Java,
and you can bypass those security checks using setAccessible(true).

I don't see why we should change that:
  - Class.forName() should throw a ClassNotFoundException if the module of the class is not declared as dependency.
  - invoke() should throw a an IllegalAccess exception if the module of the class is not declared as dependency.
  - setAccessible() should allow to bypass the security check and works as in pre-module world.

I don't see the point to either add a new security check on setAccessible or to allow reflection between modules that are not listed in the dependencies.

Rémi

----- Mail original -----
> De: "David M. Lloyd" <david.lloyd at redhat.com>
> À: jpms-spec-experts at openjdk.java.net
> Envoyé: Mardi 15 Septembre 2015 14:01:07
> Objet: Revisiting encapsulation requirement
> 
> Experts, I think we should revisit the "Encapsulation" requirement with
> a view towards removal.
> 
> The requirement is:
> 
> > Encapsulation — The access-control mechanisms of the Java language and
> > virtual machine must prevent code from accessing classes and interfaces in
> > packages that are not exported by their containing modules, or in packages
> > whose containing modules are not required by the module containing the
> > code. These mechanisms must be operative even when a security manager is
> > not present.
> 
> The implementation amounts to modifying the
> AccessibleObject.setAccessible() implementation for classes to perform a
> check of the caller's class loader before determining whether to make
> the object accessible.
> 
> As Rémi pointed out, this check is easily bypassed by using reflection,
> by reflecting on AccessibleObject.class itself - since all modules
> require "java.base", all modules implicitly can bypass this check.  But,
> even assuming this could somehow be patched over, I think we should
> consider dropping this requirement; I have two primary reasons for this
> (though there may be others as well).
> 
> The first reason is that without a security manager (or maybe even
> *with* a security manager - but that's another discussion), it is
> inevitable that any security measure used to protect this mechanism will
> ultimately be bypassed, rendering its security value useless; adding
> more complexity to the system to do so will only increase the overall
> vulnerability of the platform.
> 
> The second reason is that it is often useful to gain access to and
> inspect public classes that are not necessarily visible from your
> module.  Frameworks do this commonly for example - framework
> implementations will almost never import modules that they introspect.
> 
> I think in the end users will find it more convenient and intuitive (and
> no less secure in any real sense) if public classes remain accessible.
> In the absence of any dissent, I would move that we drop this requirement.
> 
> --
> - DML
>