RFR: 8229773: Resolve permissions for code source URLs lazily

Peter Firmstone peter.firmstone at zeus.net.au
Fri Sep 13 22:07:15 UTC 2019

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.

More information about the core-libs-dev mailing list