On Mon, Jun 14, 2021 at 6:47 PM Peter Firmstone <peter.firmst...@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.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. 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
