New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages

[David M. Lloyd]

On 11/01/2016 10:09 AM, Andrew Dinn wrote:
> On 01/11/16 14:39, David M. Lloyd wrote:
>> On 11/01/2016 09:23 AM, John Rose wrote:
>>> On Nov 1, 2016, at 10:22 AM, Jochen Theodorou <blackdrag at gmx.org> wrote:
>>>>
>>>> Can we clarify "privileged code"? Privileged like in a
>>>> SecurityManager in a PrivilegedAction for example, for privileged
>>>> like only jdk internal code? Just to see it black on white ;)
>>>
>>> Good question:  I mean the basic JDK platform implementation.
>>> Something deep in java.base.  Like Unsafe.
>>
>> I don't see why this can't be a "regular" API though, rather than a
>> super-user sledgehammer every single time.  If user code can be
>> statically granted access, and that user code can deliberately acquire a
>> narrowly-scoped object which can access those Lookups/*Handles, then
>> isn't that better than using Unsafe, which not only represents
>> unrestricted system-wide access, but can undermine even the JVM's
>> integrity if leaked?
>
> If making this a 'regular' API means allowing any code to use it then
> that clearly undermines /all/ the access restrictions provided by
> modules. The point is not to unlock all doors in the castle but to open
> doors for trusted code when needed (and only then).

Maybe I wasn't clear; I was suggesting that any code be able to use the 
API, but only to access things which were explicitly granted.  I'm 
suggesting *less* access, not *more*.

Saying "suitably privileged" and "Unsafe" seems sufficient until you 
realize that many many frameworks will need this API, which means they 
will need Unsafe, which means they will *get* Unsafe (one way or 
another), which is certainly a far more dangerous thing to have floating 
around than (say) a Lookup that has access to a few specific private 
members.

> There is a very easy way to provide tightly controlled access to a
> framework. Export access to e.g. jdk.internal.misc.Unsafe or e.g.
> java.lang.[invoke].MethodHandles to a nominated module provided by your
> framework then arrange for that module to hand out Lookups (or better
> MethodHandles) to framework code as and when they are needed via a
> private channel. You can do arrange that with a single addExports option
> on the command line and a very small amount of setup code to establish
> the private channel

I don't see how this is safer though.  You're proposing to hand all the 
keys (or none) to modules which don't need all the keys, whereas I 
propose that a module should only gain incremental additional access on 
a grant basis.

At least Rémi's approach requires a specific grant and non-Unsafe 
vector, though as I said the weaknesses (of his first approach) are that 
the grant must come from the target class (programmatically) instead of 
being a static declaration ("opens" is a natural fit for this if I 
understand the proposal correctly).  The other weakness is that it 
requires class init, but that's purely a consequence of requiring a 
programmatic grant as far as I understand.

Rémi's newest Gist uses an annotation, which is closer but not quite on 
the target IMO.  An annotation cannot be module-deployment-agnostic in 
the way that I outlined previously (hence 
#IndirectQualifiedReflectiveAccess); ultimately accessibility 
information ought to come from the module configuration itself.

-- 
- DML