Revisiting encapsulation requirement
David M. Lloyd
david.lloyd at redhat.com
Thu Sep 17 15:40:14 UTC 2015
On 09/16/2015 04:00 AM, Remi Forax wrote:
>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>> À: jpms-spec-experts at openjdk.java.net
>> Envoyé: Mardi 15 Septembre 2015 23:06:35
>> Objet: Re: Revisiting encapsulation requirement
>> On 09/15/2015 02:47 PM, Remi Forax wrote:
>>> Hi David,
>>> ----- Mail original -----
>>>> De: "David M. Lloyd" <david.lloyd at redhat.com>
>>>> À: jpms-spec-experts at openjdk.java.net
>>>> Envoyé: Mardi 15 Septembre 2015 18:12:56
>>>> Objet: Re: Revisiting encapsulation requirement
>>>> Do you have an example of a real-world problem (security or otherwise)
>>>> that is solved by adding access checks based on the caller ?
>>> You take the problem by the wrong side :)
>>> Let's suppose you agree that both the notion of visibility (private,
>>> package private, etc) and the reflection API are something useful.
>> Sure, we've been calling that "accessibility" up until now.
>>> A simple model is to make the Java visibility rules and the reflection API
>>> behavior aligned.
>>> This implies that some reflexive calls have to be caller sensitive.
>>> Then as i said earlier, you need a way to escape the sandbox, a escape
>>> hatch, to program things like meta-protocols as most of the Java EE specs
>>> are, hence, the addition of setAccessible().
>> So if I understand correctly, you propose that, in addition to verifying
>> that the target type is accessible to the caller, we should also verify
>> that it is visible when we do the actual access check (i.e. "invoke()
>> should throw...if...the class is not declared as a dependency") and
>> forget doing a special check when we call setAccessible(). If I'm
>> misunderstanding you, stop me here!
>> But assuming all that is true, my concern is that today, I can access
>> any public member of any public class in the system that I can get a
>> Class object for, even if it comes from a different, isolated class
>> loader. Under the new rules and even with your suggestion, a class has
>> to be public *and* visible to me, else setAccessible() is the only
>> choice - even if it's public, and was handed to me! To me this makes no
>> sense and does not add any security- or encapsulation-related benefits
>> that I can come up with - quite the opposite actually, since now you
>> need to be granted sweeping permissions to access it. This is why I'm
>> seeking a counter-example which supports this idea.
> Let say you have two modules, one that contains an interface
> and another that contains a class that implements that interface in another package.
> currently if you write a code like this:
> by accessing to a public method of the implementation class that may be not declared in the interface,
> you're breaking encapsulation.
> if you write:
> Interface o = ...
> there is no problem.
> but maybe it's not a problem that worth to be fixed ?
Yeah you don't always have an interface though, let alone one in a
common ancestor module. To me "public" should mean "public".
More information about the jpms-spec-observers