Thanks Andrew,
For the simple case, of replacing the SecurityManager stack walk, one
could use reflection.
Thank you for also confirming that is not possible (or at least very
unlikely) to add a GuardBuilder to Java 8, the proposal is for JDK code
to use a provider mechanism, to intercept permission checks, so custom
authentication layers can be implemented, this could be accepted in
future versions of Java, but not existing. As it is said, there is no
harm in asking.
The advantages of being able to address issues with Permission
implementations and customise, for example, by providing a replacement
for SocketPermission, that doesn't call DNS, and allows wild cards for
subnets, would be significant for the simplification of authorization.
So developers might hope to be able to implement a significantly
improved authorization layer for a future version of Java, provided we
have some basic things like JVM hooks for access checks.
--
Regards,
Peter Firmstone
On 23/06/2021 7:19 pm, Andrew Dinn wrote:
OHi Peter,
n 23/06/2021 04:02, Peter Firmstone wrote:
1. StackWalker - Can stack walker be back ported to Java 8?
The right place to ask about this is the jdk8u updates project list.
However, you probably don't need to ask there because the answer is
almost certainly going to be a very loud no.
JDK8u is in long term maintenance mode. The goal of the updates
project for that release is to fix security issues and critical bugs
*and nothing else* so that existing deployments remain stable as far
as possible. Except when required to meet those goals backporting of
new functionality is done only under exceptional circumstances.
The only recent examples of new function backports that I am aware of
have involved merging up functionality from downstream releases in
order to 1) unify the platform and 2) enable downstream contributors
to help to maintain a single, standard release i.e. highly exceptional
cases where there was a problem for existing users. Your request, by
contrast, is exactly the sort of case that maintainers are trying to
avoid -- it will introduce change with no gain and the potential of
breakage for the vast majority of users.
If you want to deal with deployments pre and post removal of the
Authorization support that you currently rely on I suggest you
consider doing that by using a multi-release implementation and
package it using the multi-release jar format. If you don't like the
idea of multi-release jars you can still implement a standard jar
format solution using a provider model. However, you will still need
to build the alternative provider jars using the relevant JDK releases
so that different providers can rely on different JDK capabilities..
regards,
Andrew Dinn
-----------
Red Hat Distinguished Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill
