RFR (12): 8191053: Provide a mechanism to make system's security manager immutable

[Peter]

Hi Alan,

Ok will do.  I'm guessing the test case needs to be a jtreg test?

I haven't used lambda's in a SecurityManager implementation at this 
time, but will experiment and see what happens.   Perhaps an comment in 
the documentation around implementation and recursion difficulties would 
be sufficient?  When implementing a SecurityManager, or Policy, the best 
way to avoid recursion issues, is to ensure that all necessary classes 
are loaded before the SecurityManager or policy provider are in force, 
during construction, or static initialization and that the 
SecurityManager or Policy has AllPermission.

Non-blocking concurrency also eliminates recursive blocking issues.

In my implementation, the policy provider is effectively immutable 
(apart from one volatile reference used during refresh calls), mutable 
state in PermissionCollection instances is thread confined and unshared, 
Permission instances also have to be called after construction but 
before publication to ensure effective immutability, permission implies 
checks are performed concurrently on all ProtectionDomain's in the 
AccessControlContext and implies checks on AccessControlContext are also 
free to occur in concurrently.

I can donate only the parts of the code that I alone have authored, 
should the JDK wish to go down this path.   I am the sole author of 
parts that may the be most useful however, as they store the existing 
policy file structures in memory, allowing PermissionCollection 
instances to be created on demand without blocking, but they do depend 
on RFC3986 URI (of which I'm not the sole author, I might be able to 
track down other authors).

Regards,

Peter.

On 19/09/2018 5:51 AM, Alan Bateman wrote:
> On 18/09/2018 15:07, Peter wrote:
>> Hi Alan,
>>
>> I'm a little time poor presently, but will put it on my todo list.  
>> Admittedly this is one part of the JVM that could have better test 
>> coverage.   Implementing a custom SecurityManager was fraught with 
>> recursion difficulties,
> If you can get time to try to reproduce with a JDK 11 or 12 build then 
> it would be useful. As things stand there are still issues with using 
> lambda expressions in the checkPermission method [1] but I believe the 
> other recursive initialization issues that arise with malformed policy 
> files or lcating resources for exception messages have been resolved.
>
> -Alan.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8155659