My position on module security/access control

[Ali Ebrahimi]

Hi,

On Thu, Dec 10, 2015 at 4:59 AM, <mark.reinhold at oracle.com> wrote:

> 2015/11/18 8:10 -0800, david.lloyd at redhat.com:
> > 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.
>
> If I understand correctly, you're proposing that a public type in a
> non-exported package be accessible via reflection, but not via static
> references in source or class files.  (There would still have to be some
> way to declare whether the public types in a package are exported for
> use in static references, but how that's done is a different issue.)
>
> You argue that "public" should always mean "public", yet your proposal
> would change the meaning of "public".  To tell whether something marked
> "public" is accessible statically from outside a module, a developer
> would still have to consult the file (in whatever format) in which the
> relevant package is declared to be exported (or not).  "public" inside
> a module would still have a different meaning than "public" outside a
> module, and a different meaning from what "public" meant in Java 8.
>
> So, do you want to preserve the meaning of "public", or not?
>
> Your proposal would, further, introduce an asymmetry between access
> control in the language and the VM vs. access control in the reflection
> APIs.  With the exception of escape hatches such as setAccessible, the
> reflection APIs have always worked in exactly the same way as the
> corresponding static constructs.
>
> Your proposal would address the issue of making it easier for frameworks
> to migrate to modules, but it is not the only approach to that problem
> (about which more later).
>
I think what we want is manageable strong encapsulation. The current design
implements strong encapsulation but does not provides (enough) utilities
for manageability.
What that I propose is support for friend or privileged modules. The module
authors can grants some special permissions to privileged modules such as
full reflective access control.
Use cases:
DI frameworks needs access and manipulate private members, instantiate
non-exported implementation classes and similar use cases applies to JPA
frameworks.
In this cases dynamically adding read edges to framework module's
dependency list does not help. We can here add inverse dependency and
declare dependency in user module not in framework module that is not aware
of user modules.

> 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
>
>
> The design as proposed, by contrast, narrows rather than widens an
> existing access mode (public), so security is not an issue, and it
> narrows that mode in a way that's relatively easy to explain -- just
> consult the relevant module declaration.
>
I support current design in this case.

>
> > 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.  ...
>
> There's no need to extrapolate, since we captured this requirement
> explicitly [1].
>
> (I don't see a specific proposal here, so I have no further comments
>  on this point.)
>
I think Mark points to use cases I listed above.


>
> > 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.
>
> I agree that, as a proof point, it'd be nice to implement ServiceLoader
> using only reflective operations that are also available to non-system
> modules.  ServiceLoader is, after all, just a small kind of framework.
>
> Services are bound and provisioned by the module system itself, however,
> so ServiceLoader does, of necessity, have some special privileges, and I
> don't think that can be avoided.
>
I think friend or privileged modules can help here.


-- 

Best Regards,
Ali Ebrahimi