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).
On Thu, Apr 29, 2021 at 1:48 AM Peter Firmstone <peter.firmst...@zeus.net.au> wrote: > We also use the SecurityManager for caller sensitive method calls. > > I re-implemented a secure implementation of Java Serialization, using a > public API and fewer features (eg no circular links), in this > implementation, each class in an object's hierarchy has its own > namespace, the calling class is discovered using a SecurityManager > subclass. > > -- > Regards, > > Peter Firmstone > 0498 286 363 > Zeus Project Services Pty Ltd. > > On 29/04/2021 3:37 pm, Peter Firmstone wrote: > > Which version of Java is this planned for? Will the last version > > supporting the security manager be a long term support version, eg > > back ports of security patches and TLS technologies? > > > > We have our own security manager implementation and policy provider > > implementations. Both of these are high performance and non-blocking > > and we are able to dynamically grant and revoke some permissions. > > While I acknowledge the Java policy implementation has a significant > > performance impact, due to blocking permission checks, ours is less > > than 1%. Our software doesn't share PermissionCollection instances > > among threads, or even have a Permissions cache, > > PermissionCollection's are generated for each permission check and > > discarded for garbage collection, the Permission object themselves are > > cached (after initialization and safe publication), as are the results > > of repeated permission checks. We also have our own Permission > > implementations. > > > > We have tools that generate policy files with least privilege, > > although we will manually alter them with wildcards, for network > > connections for instance. > > > > In our software, dynamic permissions are granted after authentication > > of TLS connections. > > > > It is too early for me to tell if there are suitable replacement > > technologies available. I can understand the motivation for reducing > > Java's software development burden, but I think this version of Java > > might be the last for us, it would certainly be good if a long term > > support version was available, perhaps indefinitely lol. > > > > Regards, > > > > Peter Firmstone > > Zeus Project Services Pty Ltd. > > > > > > On 16/04/2021 4:05 am, mark.reinh...@oracle.com wrote: > >> https://openjdk.java.net/jeps/411 > >> > >> Summary: Deprecate the Security Manager for removal in a future > >> release. The Security Manager dates from Java 1.0. It has not been > >> the > >> primary means of securing client-side Java code for many years, > >> and it > >> has rarely been used to secure server-side code. To move Java > >> forward, > >> we intend to deprecate the Security Manager for removal in concert > >> with > >> the legacy Applet API (JEP 398). > >> > >> - Mark > > > > -- - DML • he/him
