Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)

[Andrew Dinn]

On 26/09/16 14:19, Alan Bateman wrote:
> On 26/09/2016 12:36, Andrew Dinn wrote:
> 
>> :
>> I addressed that in the text you snipped. The one point of relevance is
>> that which the original poster asked about:
>>
>>    -- Why do we need Jigsaw to constrain access control when we can do so
>> using a security manager?
>>
>> Do you (or anyone else involved in defining and implementing Jigsaw)
>> have an answer to that question?
> This project updates the Java Language to support modules. The access
> checks that we are talking about happen at compile time and run time.
> The access checks happen irrespective of whether there is a security
> manager or not (and of course there is no equivalent at compile time).
> I'm not sure that there is much more to say on this, the security
> manager is not really relevant to what we are doing here.

I think those involved in this discussion already know all that you have
stated here regarding /what/ this project is doing. The present question
is /why/ is something that it is doing needed. It seems that there has
been no real explanation of this on the JSR EG list. You seem to be
unwilling to offer any real explanation here. I cannot see a failure to
provide such a rationale as less than failing to live up to the open
source consultation process that this project is meant to be following.
Perhaps someone on the Governing Board could step in here in order to
consider this lacuna?

>> Also, you have used the phrase twice now so I have to ask. Where does
>> the notion that the "legacy security manager mechanism" is actually a
>> legacy mechanism come from? Is it to be retired? Or are you just saying
>> that you think it ought to be legacy because you think Jigsaw makes it
>> redundant?
> Sandboxing with a security manager is legacy and has been highly
> problematic for a long time. It has not been retired although I think a
> good discussion for elsewhere on whether it should be deprecated. The
> only connection to modules is that strong encapsulation makes the
> platform more secure. Modules is not a replacement for the security
> manager.

It id difficult to see the security manager mechanism as being as
unquestionably 'legacy' and 'highly problematic' as you assert when the
person who asked the question stated:

  "For deployment, I’ve always used the security manager to
limit/control access when I take some 3rd party code/jar and deploy it
into a production environment.  That helps me restrict its access to
resources in a manageable and maintainable way."

Your response here comes across as a refusal to entertain the legitimacy
of the original question yet it seems to me to be a perfectly legitimate
question. You have not actually provided any evidence as to why use of a
security manager to manage access is inadequate or, at least, inferior
to the control that Jigsaw provides. If you or the project devs don't
know that then who is to explain why the latter is being added to the
JDK runtime?

Also, I am still concerned at your use of the word 'legacy'. Not only
has this mechanism not been 'retired', you acknowledge that there are no
such plans afoot. In what sense can a feature be 'legacy' when it is
part of the implementation, has not been marked as deprecated, has no
accepted alternative (not until Jigsaw is agreed) and is happily
employed by (some) current users. To me that's a very strange form of
'legacy'.

  . . .

> There is is nothing being waved away or taking lightly. This project has
> a stated goal to provide support for strong encapsulation. This has a
> lot of implications that we've trying to work through. We of course know
> that strong encapsulation isn't for all modules, hence the proposal on
> the JSR list to provide a simple means to get the benefits of reliable
> configuration without opting in to strong encapsulation.

That's very good to hear, because your previous phrasing certainly
brought that commitment into question. As I am afraid does your
continued unwillingness to provide motivation for why the current Jigsaw
implementation operates in the way it does.

n.b. I'm not saying this because I personally want to see Jigsaw
drastically changed (although I know others, such as my colleague David
Lloyd, have good reasons for requesting significant changes). No, it's
rather because I think it is important that the rationale for one choice
over another conflicting choice is articulated openly so that the
consequences of making or rejecting any such choice can be understood
and their pros and cons correctly weighed in the balance by all OpenJDK
project members and users who are willing to expend the effort needed to
understand and review those consequences. Isn't that how this project is
supposed to work?

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander