Revisiting encapsulation requirement

[David M. Lloyd]

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 :)
>>
>> Maybe.
>>
>>> 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!
>
> yes,
>
>>
>> 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:
>    o.getClass().getMethods("foo").invoke(o)
> 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 = ...
>    Interface.class.getMethods("foo").invoke(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".

-- 
- DML