On 09/28/2016 04:37 AM, Gunnar Morling wrote:
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?
I don't think that is what those folks asking about using the SM had in
mind.
Rather, the idea would be - IIUC - to grant code in module B (say an ORM
tool) reflective access to non-exported (and of course exported) types in
module A (say a module with entities) by default. If needed, the code in B
would then use setAccessible() for making private members in A accessible
before invoking them, allowing it to obtain the entity state. This is where
the SM is part of the picture: if in a given environment the user wants to
restrict who may call setAccessible(), they could use the SM for it, with a
fine grained policy, e.g. allowing the call only to the ORM module.
I.e. ReflectiveAccessToNonExportedTypes would be granted by default, only
if an SM is enabled at runtime, actions to suppress accessibility checks
would be subject to the current security policy.
This is not to say that I'm behind this idea, I just felt it hasn't been
discussed in the way it may have been meant.
I can see though how JDK devs and library authors want to prevent access to
private code in their modules at all, hence relying on the SM to be enabled
at runtime is not an option to address that requirement.
Note that as a security mechanism for untrusted code, this mechanism is
not going to be adequate no matter what. The person who has control of
the deployment environment can always change the module to accommodate
their case. I'm sure it will be a very short time after finalization
before we see module editing tools in the wild to accomplish exactly
this. This is an inevitable consequence of bundling the module
definition within the module itself.
Only the JDK has any real ability to enforce this kind of security,
though of course it's always possible to defeat that as well (it's just
potentially a lot more work).
The chief tangible protection which is expected to be afforded by this
mechanism is against malicious exploitation of trusted code.
--
- DML
