It's not too late for access control

[David M. Lloyd]

On 07/12/2016 04:53 AM, Alan Bateman wrote:
> On 11/07/2016 15:21, David M. Lloyd wrote:
>
>> The crux of this access control discussion is that, up until JDK 9,
>> "public" meant "public".  End of story.  If you did not want something
>> to be visible, you made it not public.  Very simple and very clear.
>> The word "public" literally means "accessible to all" after all;
>> that's why the term was selected in the first place, and it is nearly
>> certain that this was the intent of the thing up to this date.
>>
>> What is being required in the JPMS spec, and, I dare to suggest, what
>> has been generally asked for by the public (and even required by the
>> JDK), is a way to provide an additional capability - the ability to
>> selectively share otherwise unshared code.
>>
>> The existing Java language accessibility model is (of course)
>> well-understood by experts.  For new developers, the concepts takes a
>> bit of time to explain but can generally be grasped.  In the end the
>> accessibility of a member is generally easily determined by examining
>> the qualifiers of that member.
>>
>> What has been proposed and implemented in Jigsaw is essentially a
>> completely new approach to access checking.  Because it is new, and
>> because it is essentially untried, I predicted that issues would arise
>> not unlike the ones being currently discussed.  I argue that this
>> approach is not optimal, for at least reasons discussed on this list
>> and in this email, but that even now, it's not too late to change the
>> approach.
>>
>> I propose, once again, that rather than changing the meaning of
>> "public" to something unintuitive (and indeed counter to the
>> definition of the actual word), we instead allow the selective
>> extension of package-private.  Users would make public any type or
>> member which is *meant* to be public, i.e. accessible by all. Rather
>> than (at best) changing their expectations as to the behavior of
>> "public" only to immediately betray that expectation by forcing them
>> through a backdoor in order to meet practical needs, we ensure that
>> their expectations remain: public members are public, and things that
>> are secret are not public.
>>
>> Conceptually (and, hopefully, technically) this should not be too far
>> away from where we've arrived at now in Jigsaw, at least as far as the
>> package inventory is shared between modules for the purpose of access
>> control.  Can anyone think of any good reason we should *not* do this,
>> or ways that this would be substantially weaker than restricting public?

> It's hard to know where to start on this as what you proposing would
> have massive implications. I think what you are proposing is to drop the
> notion of exporting packages. You didn't mention the dependency module
> or the concept of readability - are you suggesting to drop that too?

No, exporting and dependencies would remain.  The concept of readability 
would go, I think, as it wouldn't add anything (and I'm really not sure 
it adds anything today, as the "direction" of the readability grant 
seems backwards to me in terms of security).

> I can't tell if you've grokked that this is the basis for reliable
> configuration.

Module linkage can still be reliable using only an exports graph, and 
keeping public as public.  We've been doing it for years.

> You haven't said how I could release a library that works
> on the class path in some environments and as a module in other
> environments.

You would not need to make any changes to most libraries.  If you wanted 
to export package A to package B in a non-module environment, and if we 
wanted to support that, I don't see it being any more difficult than, 
say, supporting *both* module dependencies *and* Class-Path.

> I don't see how you proposing to do the equivalent of
> qualified exports.

It wouldn't have to be any different; instead of re-enabling public 
access to a dependency, you'd have the option to enable private access, 
thus ensuring that security expectations are consistent: accessibility 
is never weaker than a module author expects.

>  I could go on, smarter much people than me could go
> further, but I'm not sure that it's worth spending time on now.
>
> At a high level then I think it's important to understand that a lot of
> time has been put into the design.

I have sympathy for this, and I also understand (as well as anyone, 
trust me) that it is possible to spend a lot of time thinking about a 
design only to find a problem at the end.  The amount of time spent on a 
design is no proof against changing it.

> The proposal in the JPMS has to take
> account that the core platform is very mature. This means compatibility,
> migration and co-existence with the existing world significantly
> influences the design.

Of course!  That's the main point of this: the export access controls 
are so completely incompatible that just about every reflective 
framework - and there are many, many of them (a couple searches on 
GitHub yield hundreds of thousands to millions of Java code results) - 
will break.  Every single one of these bits of code are going to assume 
that a public member in a public type can be publicly accessed. 
Compatibility means public stays public.  This is the "real" world.

> I have no doubt that if the modules were in the
> Java Language from the start or adding in the early days then the design
> would be different. As regards changing `public` so that it no longer
> implies "accessible to all" then it is unfortunate but it's a change
> that you should be able to get used too quickly.

How can one massive compatibility change be "unfortunate" while another 
is otherwise somehow invalid?

-- 
- DML