On 01/11/16 15:35, David M. Lloyd wrote:
> On 11/01/2016 10:09 AM, Andrew Dinn wrote:
>> 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.
No, I'm suggesting handing the keys to a single module provided by your
framework -- which module will then use a key to open a room on demand
for your code and your code only. That means the privilege can be
granted using one command line switch with use of that privilege
controlled by a runtime mechanism of your choosing.
> 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.
I did actually suggest a way of avoiding the use of Unsafe. You give
your nominated module full reflective access to java.lang.invoke
allowing it to create Lookup instances (it can actually just create a
single all privileges lookup and use this to clone others). You don't
need to insert a class into java.lang.invoke to do this. You simply add
one exports directive on the command line.
> 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.
If you implement a module with the ability to hand out Lookup instances
you can use whatever control model you like. For example, you might park
an instance which hands out Lookups in a location only available to your
framework or ensure that any caller asking for a Lookup belongs in a
package implemented by your framework or whatever you want. the point is
that once you have granted a class in our code the ability to create
Lookups you can implement whatever runtime access control you want.
Clearly,as John said, you need to do that responsibly.
regards,
Andrew Dinn
-----------
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
