Revisiting encapsulation requirement
David M. Lloyd
david.lloyd at redhat.com
Thu Sep 17 15:09:01 UTC 2015
On 09/17/2015 09:57 AM, mark.reinhold at oracle.com wrote:
> 2015/9/15 5:01 -0700, david.lloyd at redhat.com:
>> 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.
> I think it's premature, less than a week after the publication of the
> initial design and first early-access builds, to propose that we drop
> this central requirement.
> I suggest that we instead focus on the design as proposed, and figure
> out how to make it better.
>> The implementation amounts to modifying the
>> AccessibleObject.setAccessible() implementation
> This one method is just a small part of the overall encapsulation story,
> which is described in detail in the SotMS document.
>> for classes to perform a
>> check of the caller's class loader before determining whether to make
>> the object accessible.
> No, that's not exactly right; please see my detailed reply to RÃ©mi.
>> 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.
> A simple bug, easily fixed.
>> 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.
> Yes, security is hard. That's not a reason to give up on it.
Of course not. But as far as I can tell, it has yet to be shown that
this requirement and its corresponding implementation changes actually
improve security in any real way. I'm not talking in hand-wavy
generalizations like "encapsulation leads to better security", I'm
talking about brass-tacks examples.
>> 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.
> Frameworks in their current form often work as-is on the class path,
> because of the way that unnamed modules work, as discussed in my reply
> to RÃ©mi. See, e.g., Peter Levart's report on the jigsaw-dev list .
Correct me if I'm wrong, but you seem to be making an assumption here
that no existing artifacts can or should be "graduated" as-is into
modules. This is further underscored by this statement:
> If you convert a framework (or any other code) into a module then you can
> use the Module::addReads method  to add read edges to the module
> graph at run time. This is, in effect, an API that allows a module to
> `require` additional modules dynamically.
The compatibility story is getting increasingly foggy here. On the one
hand, for example, "JDK 9 retains this three-level hierarchy, in order
to preserve compatibility" - a hierarchy that as far as I can tell,
very, *very* few existing things actually care about - but on the other
hand, nothing in the Jigsaw module system prototype is compatible in any
way with the class loading world as we know it - which very *very* many
existing things rely on.
>  http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-September/004537.html
>  http://openjdk.java.net/projects/jigsaw/spec/sotms/#increasing-readability
>  http://cr.openjdk.java.net/~mr/jigsaw/spec/api/java/lang/reflect/Module.html#addReads-java.lang.reflect.Module-
More information about the jpms-spec-observers