[Nestmates] RFR: 8199309: [Nestmates] The new Class nestmate methods should have SecurityManager checks
john.r.rose at oracle.com
Mon Mar 12 04:32:52 UTC 2018
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.)
More information about the valhalla-dev