On 15/06/2021 2:23 am, David Lloyd wrote:
On Mon, Jun 14, 2021 at 2:38 AM Peter Firmstone
<peter.firmst...@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.bate...@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.
