<div dir="ltr"><div dir="ltr">On Thu, May 6, 2021 at 12:48 PM Alan Bateman <<a href="mailto:Alan.Bateman@oracle.com" target="_blank">Alan.Bateman@oracle.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 06/05/2021 11:26, Peter Firmstone wrote:<br>
><br>
> OpenJDK seems to have assumed that no one was using SecurityManager <br>
> based on one research report.<br>
><br>
I don't think this is right. Instead I would say that many of us have <br>
rarely encountered deployments on the server-side that are using a <br>
SecurityManager to enforce security as envisaged by the Java security <br>
model. I've been at Java conferences where the sessions on this topic <br>
had less than 10 people in the room. Most of the actual usages that I've <br>
come across have been more like using the security manager as a <br>
convenient way to intercept network and file access for the purposes of <br>
logging or blocking. These usages may not have a need for protection <br>
domains, stack walks, policy files and the other complexity that comes <br>
with the security model.<br></blockquote><div><br></div><div>We're (partly, at least) in that group. We can't block the access from outside<br></div><div>the JVM (and we are containerized with restricted permissions already) because<br>some accesses are legitimate - something outside the JVM doesn't know when<br>the JVM is executing a particular piece of code, so we toggle the Security Manager<br>on and off depending on context.<br><br></div><div>And here's the thing; there isn't really anything in the proposal that addresses this<br></div><div>use case, or offers an alternate way forward.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
One thing that is missing from the discussions here is the cost and tax <br>
that supporting the SM "operating mode" brings. Many of the big features <br>
and all changes to security sensitive code must pay this tax. If there <br>
is a bug, a missing checkPermission for example, then it gets treated as <br>
security vulnerability at massive cost. Everything asynchronous brings <br>
more complexity and effort to figure out where the checks should be and <br>
whether an AccessControlContext needs to be carried around. I look <br>
forward to the day where we can be like other languages and runtimes <br>
that don't have to be concerned with this complexity and optional way of <br>
running.<br>
<br>
Finally, just to point out again that this JEP is about deprecating for <br>
removal in the future, it doesn't propose to remove the security manager <br>
now. If it moves forward then it will probably be several releases of <br>
degradation before it is removed. That gives time to properly consider <br>
the use cases where the security manager is useful today. Also if it is <br>
eventually removed, then anyone that really depends on this world can <br>
continue to use supported releases for years to come.<br></blockquote><div><br></div><div>I appreciate that there will be older versions we can run; the issue is always<br></div><div>that there may be some external driver why we have to update - either to gain<br></div><div>a critical feature, or because something else doesn't support the old version.<br><br></div><div>I know I would feel a lot happier with this proposal and its implications if the<br></div><div>consideration of those use cases where the security manager is useful today<br></div><div>was more fully fleshed out.<br><br></div><div>Thanks,<br></div></div><br>-- <br><div dir="ltr">-Peter Tribble<br><a href="http://www.petertribble.co.uk/" target="_blank">http://www.petertribble.co.uk/</a> - <a href="http://ptribble.blogspot.com/" target="_blank">http://ptribble.blogspot.com/</a></div></div>