RFR: 8229773: Resolve permissions for code source URLs lazily

Peter Firmstone peter.firmstone at zeus.net.au
Fri Aug 16 10:40:16 UTC 2019


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 security-dev mailing list