RFR: 8229773: Resolve permissions for code source URLs lazily

[Peter Firmstone]

Hi Claes,

So this security manager is part of a much larger program, (a fork of 
Jini / Apache River), I've almost finished the transition from Java 8 to 
Java 11...

One change I noticed is permissions granted to the java extension 
directory are now granted to every domain in our policy provider as the 
java.ext.dirs property is now blank, I also had to grant permissions to 
a number of jdk modules, after fixing these, everthing running as 
expected, except for a few minor test failures.

Next step will be to test against the EA builds.

On 17/08/2019 7:24 AM, Peter Firmstone wrote:
> 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.
>>>>
>>>>
>>>
>