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

[Peter Firmstone]

On 15/06/2021 2:23 am, David Lloyd wrote:

> 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

Logic behind this choice:

SecurityManager depends on Permission, currently there are Permission 
checks throughout the JVM, however Permission implementation classes 
will be removed, although the Permission class itself won't be.

Permission references can be replaced with Guard references (which 
Permissions are instances of).

The Permission implementations of Guard::check call SecurityManager, so 
checks will continue working as expected, but it allows us to intercept 
them and do something different.

By replacing Permission references with Guard, it allows us to implement 
our own checks in these locations, and OpenJDK doesn't need to maintain 
Permission instances, and or, we don't need to make use of unmaintained 
Permission implementations.

There are already issues with Permission implementations, take for 
example SocketPermission, it consults DNS and it isn't possible to enter 
a range of IP addresses (such as the local subnet, and a list of public 
IP addresses), for now, every single IP address must be entered and this 
isn't practical.   The proposed API would allow us to re-implement 
SocketPermission functionality, as well as other Permission implementations.

This proposal also allows every existing component of the SM 
architecture to be removed, while retaining the most important 
component, the checks themselves, such that you or I or anyone else for 
that matter can re-implement the functionality of SM.

SM and friends will be removed eventually, so now is our opportunity to 
get something in place that has minimal impact on OpenJDK maintenance, 
that will remain.

> (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.

Yes, one can do that, but these classes will also eventually be removed.

-- 

Regards,
  
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.