On 06/05/2021 11:26, Peter Firmstone wrote:
OpenJDK seems to have assumed that no one was using SecurityManager
based on one research report.
I don't think this is right. Instead I would say that many of us have
rarely encountered deployments on the server-side that are using a
SecurityManager to enforce security as envisaged by the Java security
model. I've been at Java conferences where the sessions on this topic
had less than 10 people in the room. Most of the actual usages that I've
come across have been more like using the security manager as a
convenient way to intercept network and file access for the purposes of
logging or blocking. These usages may not have a need for protection
domains, stack walks, policy files and the other complexity that comes
with the security model.
One thing that is missing from the discussions here is the cost and tax
that supporting the SM "operating mode" brings. Many of the big features
and all changes to security sensitive code must pay this tax. If there
is a bug, a missing checkPermission for example, then it gets treated as
security vulnerability at massive cost. Everything asynchronous brings
more complexity and effort to figure out where the checks should be and
whether an AccessControlContext needs to be carried around. I look
forward to the day where we can be like other languages and runtimes
that don't have to be concerned with this complexity and optional way of
running.
Finally, just to point out again that this JEP is about deprecating for
removal in the future, it doesn't propose to remove the security manager
now. If it moves forward then it will probably be several releases of
degradation before it is removed. That gives time to properly consider
the use cases where the security manager is useful today. Also if it is
eventually removed, then anyone that really depends on this world can
continue to use supported releases for years to come.
-Alan
