RFR 8168075: Custom system class loader + security manager + malformed policy file = recursive initialization

Mandy Chung mandy.chung at oracle.com
Thu Jan 12 20:53:56 UTC 2017

> On Jan 11, 2017, at 5:34 AM, Adam Petcher <adam.petcher at oracle.com> wrote:
> Please review the following bug fix:
> http://cr.openjdk.java.net/~apetcher/8168075/webrev.00/
> This fixes a bug in which a permission check would try to load resources while the system class loader is being initialized. Resources cannot be loaded at this time, so this change ensures that the resources are loaded earlier.

This seems a reasonable approach.  There is a slight overhead for this change when the resource bundle is never used but it’s not an issue since the initialization of a security manager is not cheap anyway.

It may be helpful to add a check to ensure that the resource bundle is loaded either VM.isBooted() or initLevel != 3.  It would make it clear of this circular bootstrapping issue.

You do this in SecurityManager class initialization.  Have you considered doing it in the SecurityManager constructor?  As Claes clarified, SM is loaded but not initialized during early VM startup.  So no issue to do it in clinit.  The alternative is to do it in the constructor as lazy initialization.

   Is the doPrivileged necessary?  It’s old code written long ago.  Perhaps we should file a bug to clean this up later. 

Otherwise, looks good.

More information about the security-dev mailing list