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

[David Lloyd]

On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone
<peter.firmstone at zeus.net.au> wrote:
> 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.

This is incorrect AFAICT.  The relevant JEP text is:

> Permission and subclasses — Other significant classes, such as ProtectionDomain, depend on Permission. Many of the subclasses of Permission, however, are specific to use cases which will likely no longer be relevant after the Security Manager is removed. The maintainers of these subclasses can deprecate and remove them separately, after evaluating the compatibility risk.

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

I guess you've got something fairly complex in mind, could you give
some practical examples of how this would work?

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

What do you envision these checks looking like?  Where would the JDK
find these Guard instances?

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

As I said I don't think there is an intention to remove the permission
classes just yet, and I don't think that it is a fair statement to say
that the permission implementations would be unmaintained.  Most of
those classes have not needed to be touched in many years; there's
just not a lot of complexity there for the vast majority of them.

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

Sure, this would be nice to clean up.  I just don't understand the
proposed mechanism.

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

Sure. This was mainly a practical observation about the current
implementation.  And any replacement third-party stack-based
authorization system could (and should) use a similar mechanism
regardless of whether these exact methods stay in the JDK for 5 or 50
more years.

-- 
- DML • he/him