RFR: 8229773: Resolve permissions for code source URLs lazily

[Peter Firmstone]

Thanks Claes,

I'll run some tests :)

Cheers,

Peter.

On 16/08/2019 9:14 PM, Claes Redestad wrote:
> 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.
>>>
>>>
>>