JEP 411: Deprecation with removal would break most existing Java libraries

David Lloyd david.lloyd at redhat.com
Mon Jun 14 16:23:13 UTC 2021


On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
<peter.firmstone at zeus.net.au> wrote:
>  1. Develop authorization layer security provider services in OpenJDK,
>     back port it to Java 8 and Java 11 (these provide most of the
>     utilised functionality of SecurityManager, allowing developers to
>     only implement those which they need, without enabling
>     SecurityManager and editing policy files).
>  2. Remove SecurityManager, Policy and Policy provider in OpenJDK 19.

The SecurityManager class itself already is *exactly* an authorization
provider.  I don't think it makes sense to consider removing the
security manager class to replace it with something that has basically
exactly the same API (specifically, a single method for each general
authorization check that can be called without constructing any new
objects, if and only if the authorization provider is installed).  See
my other proposal where, post-"removal", SecurityManager (the class)
is retained but made abstract (and sans a few methods).  All of the
existing code which performs authorization checks would be retained
and the problem solved in essentially the way you're describing, just
using existing APIs.

The security manager implementation itself can implement any kind of
authorization behavior whatsoever, based mainly on the Permission
types (which work just fine for this purpose, and anyway are already
retained by the current JEP).  Policy and its supporting classes are
completely unnecessary for implementing a security policy.  In fact,
this is the case today already.

On Mon, Jun 14, 2021 at 12:57 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
> AccessController::doPriv just runs the action.

TBH this should have always been the case.  Implementation-wise, if
one were constructing an access control context based on stack
walking, one would stop at points where `AccessController` is on the
stack (which is easily determinable) to do special work on assembling
the access control context based on the method called at that frame.

-- 
- DML • he/him



More information about the security-dev mailing list