<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If it helps, we've solved this particular problem in a couple of places by using an MR-JAR which selects an implementation using `StackWalker` when Java 9+ is used.  I will say however that it appears to be slightly less performant, which is unfortunate (but hopefully fixable at some point in the future).</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 29, 2021 at 1:48 AM Peter Firmstone <<a href="mailto:peter.firmstone@zeus.net.au">peter.firmstone@zeus.net.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We also use the SecurityManager for caller sensitive method calls.<br>
<br>
I re-implemented a secure implementation of Java Serialization, using a <br>
public API and fewer features (eg no circular links), in this <br>
implementation, each class in an object's hierarchy has its own <br>
namespace, the calling class is discovered using a SecurityManager <br>
subclass.<br>
<br>
-- <br>
Regards,<br>
<br>
Peter Firmstone<br>
0498 286 363<br>
Zeus Project Services Pty Ltd.<br>
<br>
On 29/04/2021 3:37 pm, Peter Firmstone wrote:<br>
> Which version of Java is this planned for?   Will the last version <br>
> supporting the security manager be a long term support version, eg <br>
> back ports of security patches and TLS technologies?<br>
><br>
> We have our own security manager implementation and policy provider <br>
> implementations.  Both of these are high performance and non-blocking <br>
> and we are able to dynamically grant and revoke some permissions.   <br>
> While I acknowledge the Java policy implementation has a significant <br>
> performance impact, due to blocking permission checks, ours is less <br>
> than 1%.  Our software doesn't share PermissionCollection instances <br>
> among threads, or even have a Permissions cache, <br>
> PermissionCollection's are generated for each permission check and <br>
> discarded for garbage collection, the Permission object themselves are <br>
> cached (after initialization and safe publication), as are the results <br>
> of repeated permission checks.  We also have our own Permission <br>
> implementations.<br>
><br>
> We have tools that generate policy files with least privilege, <br>
> although we will manually alter them with wildcards, for network <br>
> connections for instance.<br>
><br>
> In our software, dynamic permissions are granted after authentication <br>
> of TLS connections.<br>
><br>
> It is too early for me to tell if there are suitable replacement <br>
> technologies available.  I can understand the motivation for reducing <br>
> Java's software development burden, but I think this version of Java <br>
> might be the last for us, it would certainly be good if a long term <br>
> support version was available, perhaps indefinitely lol.<br>
><br>
> Regards,<br>
><br>
> Peter Firmstone<br>
> Zeus Project Services Pty Ltd.<br>
><br>
><br>
> On 16/04/2021 4:05 am, <a href="mailto:mark.reinhold@oracle.com" target="_blank">mark.reinhold@oracle.com</a> wrote:<br>
>> <a href="https://openjdk.java.net/jeps/411" rel="noreferrer" target="_blank">https://openjdk.java.net/jeps/411</a><br>
>><br>
>>    Summary: Deprecate the Security Manager for removal in a future<br>
>>    release. The Security Manager dates from Java 1.0. It has not been <br>
>> the<br>
>>    primary means of securing client-side Java code for many years, <br>
>> and it<br>
>>    has rarely been used to secure server-side code. To move Java <br>
>> forward,<br>
>>    we intend to deprecate the Security Manager for removal in concert <br>
>> with<br>
>>    the legacy Applet API (JEP 398).<br>
>><br>
>> - Mark<br>
><br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>