<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Sean,</p>
<p>I would be quite willing to undertake the work.<br>
</p>
<p>We have a decision to make based on when & how SM will be
removed, for obvious reasons, this decision will be delayed as
long as possible:</p>
<ol>
<li>Pull the plug on our existing Java software development
efforts, currently our software depends on SM for authorization
decisions and authentication of our secure endpoints. Our
software is built on SM and would require a complete
architecture redesign, and we simply don't have the resources to
replace decades of development effort.<br>
</li>
<li>Implement a new authorization layer to replace SM
functionality.</li>
</ol>
<p>#2 is our preferred option.<br>
</p>
<p>We need to replace permission check hooks in the JDK by
instrumenting it, as per OpenJDK advise. I had identified that
this wasn't possible to do so securely with finalizer's enabled,
from JDK18 on we can disable finalizers, so it enables us to
commence development. OpenJDK has advised that all functionality
of SM may be implemented independently by application developers
and run on top of JDK.<br>
</p>
<p>Basically I'm requesting controlled dismantling of
SecurityManager, as opposed to sudden destruction, to allow us
time to develop and implement our migration strategy.<br>
</p>
<p>Using the existing permission check hooks in the JDK allows us to
significantly speed up our development efforts. Each time a
permission check hook is removed, we will need to replace it with
instrumentation. I was hoping this could be done in a controlled
manner.</p>
<p>The first step would be to instrument Permission#checkPermission,
as this provides access to all the existing hooks within the JDK.</p>
<p>The API's changed to not throw SecurityException won't break
backward compatibility and won't impact us.</p>
<p>We haven't yet tested how our software will behave without the
PrivilegedAction's in JDK code, or preservation of
AccessControlContext in executor threads etc, but we need to start
exploring that to fully understand it before the SM removal JEP is
created.<br>
</p>
<pre class="moz-signature" cols="72">--
Regards,
Peter Firmstone</pre>
<p></p>
<p><br>
</p>
<div class="moz-cite-prefix">On 26/10/2022 5:55 am, Sean Mullan
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:7afd9392-5133-4590-1502-f01de55bc5a2@oracle.com">When
support for the Security Manager is removed, there would be little
benefit to keeping the permission checks inside the JDK, since it
would no longer be possible to set a Security Manager. Also, many
APIs that perform permission checks will likely be modified to no
longer throw SecurityException.
<br>
<br>
--Sean
<br>
<br>
On 10/25/22 2:25 AM, Peter Firmstone wrote:
<br>
<blockquote type="cite">Would the OpenJDK team consider the
following?
<br>
<br>
Where SecurityManager is invoked directly now, such as:
<br>
<br>
<br>
@SuppressWarnings("removal")
<br>
SecurityManager sm = System.getSecurityManager();
<br>
if (sm != null)
<br>
sm.checkPermission(new
RuntimePermission("setFactory"));
<br>
<br>
Can we change these routines to the simpler form:
<br>
<br>
newRuntimePermission("setFactory").checkGuard(null);
<br>
<br>
This will give us more time to transition to a replacement
authorization
<br>
layer.
<br>
<br>
We can instrument the Permission#checkGuard method, this will
assist us
<br>
to utilise existing Permission check hooks after SecurityManager
is
<br>
removed. Longer term we will need to maintain our own
instrumentation
<br>
hooks, but this will go a long way towards giving us a head
start, by
<br>
leveraging the existing.
<br>
<br>
</blockquote>
</blockquote>
<pre class="moz-signature" cols="72">
</pre>
</body>
</html>