Alternative mechanism for reflective access control (#ReflectiveAccessToNonExportedTypes / #AwkwardStrongEncapsulation)
adinn at redhat.com
Tue Sep 27 12:03:47 UTC 2016
On 27/09/16 12:34, Alan Bateman wrote:
> On the specific topic of using the security manager to do JLS and JVMS
> specified access checks then it doesn't make any sense to me. If I'm
> compiling a class A that has a reference to a member in type B then do
> you really want the compiler calling into a security manager to ask if
> this access is allowed? Security managers don't know anything about the
> access control at this level. The permission checks that a security
> manager does involve stack walks and computing the intersection of
> permissions to see if the effective permissions are granted or not. This
> is right when checking access to security sensitive resources (network
> end points or files for example) but not at the level of checking if A
> has access to a member of B. At run-time then would you really want the
> the VM calling out to a security manager when doing JVMS-specified
> access checks? If there is no security manager (the common case) then
> does it mean that code in class A can access a private field in class B.
> Going further then executing the security manager's checkPermission will
> likely involve access checks in the VM so how would you handle those?
> Hopefully you'll start to see that the access checks that we dealing
> with here are at a completely different level to the permission checks
> that a security manager implements.
Thank you for this very helpful explanation (n.b. I'm taking all
embedded questions as rhetorical). I hope it satisfies the original poster.
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
More information about the jigsaw-dev