Thanks David, will make a note of it for future reference.
Cheers,
Peter.
On 30/04/2021 12:57 am, David Lloyd wrote:
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 <mailto: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
<mailto:mark.reinh...@oracle.com> wrote:
>> https://openjdk.java.net/jeps/411
<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
