[Nestmates] RFR: 8199309: [Nestmates] The new Class nestmate methods should have SecurityManager checks

[John Rose]

On Mar 11, 2018, at 6:44 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> webrev:  http://cr.openjdk.java.net/~dholmes/8199309/webrev/
> bug: https://bugs.openjdk.java.net/browse/JDK-8199309
> 
> Mandy noted that getNestHost/getNestMembers should have security manager checks consistent with the existing getEnclosingClass et al, and this was confirmed in discussion with the EG.
> 
> isNestMateOf does not need a security check as it never exposes a Class instance. It is reworked to avoid the security check put inside getNestHost.
> 
> The existing test is updated to run a second time with the default security manager and policy in use (for which we need to add an empty policy file for jtreg to "use".)
> 
> A new test is added to trigger the expected SecurityExceptions.


Looks good, except for one thing:  The checkPackageAccess calls should
happen *after* the checks for primitives and arrays.

I don't think primitive or array classes interact well with checkPackageAccess.
At least, that path (calling cPA from a prim or array) is not well exercised,
and I'd rather not depend on it working correctly.

You can return nestHost or nestMembers from a primitive or array without
security implications, since they are self-hosting, so what comes out
of the query is only what went in.

(Hmm… the same is true of *any* self-hosting class.)

— John