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 <[email protected]> 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
