My position on module security/access control

[Tim Ellison]

David,

You raise a number of deep and interesting points here.

Rather than get into the details of each suggestion, I will say that I 
agree with the premise that the current modularity design is addressing 
visibility, while trying to live within the existing (and arguably 
sub-optimal) Java language access control model.

I have argued that the Java security model should be brought up to date, 
but I understand that requires a far reaching redesign that is beyond the 
remit of the modularity EG.  That means that modularity should 'do no 
harm', while avoiding those land mines you refer to below.

Regards,
Tim



"David M. Lloyd" <david.lloyd at redhat.com> wrote on 18/11/2015 16:10:30:

> I wanted to summarize my position on module security and access control, 

> so that all my thoughts are in one place instead of scattered across 
> various threads.
> 
> The first point I want to make is that I think that the idea of having 
> public classes that are not public is a red flag.  If a class and member 

> is public, it should always be accessible to everyone regardless of who 
> imports what module.  There should only be one access control mechanism 
> in the language.  Users already seem keen to find ways to break out of 
> the Jigsaw export-based restrictions and I think this is an indicator 
> that, while expedient, the Jigsaw approach is far from ideal.  In 
> addition I think this is an essential step towards the ultimate goal of 
> removing the dreaded setAccessible() method; if frameworks cannot even 
> access public members then they will never be able break away from using 

> reflection as a back door.  The concept being established here is the 
> ability to have a public class which is not exported but is still 
> accessible to anyone.
> 
> The second point is around module privacy.  It is clear that 
> (language-wise) we need an access level that is module-private.  Given 
> the relative uselessness of package-private accessibility in the module 
> world, I propose that any reference to a default-access-level member in 
> a Java 9 class should be considered to be a module-private access, not a 

> package-private access, in both javac and the JVM.  The protected access 

> level should be similarly widened.  This avoids the need for changing 
> the class file format or introducing new modifiers to the language or 
> reflection APIs, and ensures that the language continues to have only 
> one central access control mechanism, instead of two interacting 
> mechanisms, and completely eliminates all the "SharedSecret"-like cases 
> found throughout the JDK and elsewhere.  In the very long term, if/when 
> support for Java 8-and-earlier class files is removed, only module 
> access will remain, which results in a somewhat cleaner and more useful 
> set of access controls.
> 
> The third point is around "friend" modules.  It seems clear that we have 

> a requirement (which can be extrapolated easily from the document) that 
> some modules need the ability to provide selective access to nonpublic 
> members to other modules.  This requirement seems perfectly reasonable, 
> and the access level change described previously should be amenable to 
> this mechanism.  The mechanism could work on a package-by-package basis 
> or at a module level; I think that the distinction between the two is 
> relatively small in terms of implementation and is purely a user 
> requirements question.  The compiler and JVM should take this 
> information into account when checking access to a peer module's class. 
>   The compiler will need to know, as part of compilation, what peer 
> modules (or packages within peer modules) are expected to be accessible 
> to the currently-compiling module at run time; the means of 
> accomplishing this is a question of how the module metadata is 
> represented and stored and is not directly relevant to the issue at 
> hand, though I feel that a simple argument to javac/JavaCompiler is 
> sufficient (i.e. let the build tool, which understands how the module is 

> to be assembled and may have access to a variety of forms of metadata, 
> discover the information and pass it to the compiler).
> 
> The fourth point relates to ServiceLoader.  If ServiceLoader has a 
> unique and special blessing to bypass the access mechanism, then we've 
> failed to design an adequately flexible (and secure) access control 
> mechanism.  By implementing the three points above, ServiceLoader no 
> longer needs to be a special citizen, because all service implementation 

> classes are public (as they are today, and as they should be).  A user 
> could implement ServiceLoader in unprivileged code and it would work 
> with no special trapdoors.
> 
> My intuition is that tying exporting with accessibility hides some 
> potentially serious and maybe unsolvable land mines, and recent 
> discussion on the Jigsaw list seems to imply that there are more 
> practical problems as well.  Keeping the concepts separate and building 
> on the established accessibility mechanism seems like a much safer 
> course to me (if not as expedient), and I hope I can convince the rest 
> of the experts of the same.
> 
> -- 
> - DML
>