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 (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. -- - DML • he/him
