RFR: 8229773: Resolve permissions for code source URLs lazily

[Claes Redestad]

Hi Peter,

by explicitly ensuring the file system has been initialized before
installing a SecurityManager using a hook in System.setSecurityManager,
the patch at hand takes step to ensure things stay neutral w.r.t.
Permission initialization order when using any SecurityManager. It's not
perfectly identical, so while unlikely, there's a theoretical
possibility some implementation scenario not covered by our regression
tests might run into issues. Any help testing custom implementation on
coming EA builds would be greatly appreciated!

One thing we could do on the JDK end to reduce fragility somewhat in
this area is to provoke initialization of
sun.security.util.SecurityConstants before installing the first SM.

/Claes

On 2019-08-16 12:40, Peter Firmstone wrote:
> Hello Alan,
> 
> Yes, we are aware of those issues.
> 
> I mean documenting that system Permission classes should be loaded 
> before setting a custom SecurityManager, accessing the file system is 
> important, so if you haven't loaded the necessary classes before setting 
> a custom SecurityManager, it won't be gracefull...  The simplest way of 
> ensuring classes are loaded is by creating object instances of them.
> 
> Perhaps just a note to beware of ensuring necessary classes are loaded 
> and let developers figure out what they need.
> 
> The recursive calls are easy enough to deal with to avoid any stack 
> overflows using ThreadLocal.
> 
> inTrustedCodeRecursiveCall.set(Boolean.TRUE);
>              try {
>                  delegateContext = AccessController.doPrivileged(
>                      new PrivilegedAction<AccessControlContext>(){
>                          public AccessControlContext run() {
>                              return new 
> AccessControlContext(finalExecutionContext, dc);
>                          }
>                      }
>                  );
>              }finally {
>                  inTrustedCodeRecursiveCall.set(Boolean.FALSE); // Must 
> always happen, no matter what.
>              }
> 
> We've only really been caught out once with some jvm bootstrap changes, 
> otherwise it's been rock solid.
> 
> The other thing we do is once we've got more than three 
> ProtectionDomains on the stack is execute the ProtectionDomain implies 
> checks in parallel.  Really helps when you're making a lot of network 
> calls.
> 
> Cheers,
> 
> Peter.
> 
> On 16/08/2019 5:04 PM, Alan Bateman wrote:
>> On 15/08/2019 23:20, Peter Firmstone wrote:
>>> :
>>>
>>> The following code is included in the constructor of our 
>>> SecurityManager implementation, I suspect we may need to add some 
>>> classes to this list, perhaps this is something that needs documenting?
>> The checkPermission method of custom security manager can run 
>> arbitrary code so recursive initialization, stack overflow, bootstrap 
>> method errors, ... are always hazards. I don't know what documentation 
>> you have in mind but I don't think there is a definite list of classes 
>> that need to be loaded/initialized before the custom security manager 
>> is set because it will come down to the code that it executes in its 
>> checkPermission method.
>>
>> -Alan.
>>
>>
>