On 25/04/2022 13:53, David Lloyd wrote:
Nothing in the proposal causes splitting or delegation of responsibilities. It is _only_ about preserving security checkpoints in the JDK, which *add* a layer of checks to what the container might already provide. Nothing is being subtracted, and thus I find it hard to accept that preserving these checks somehow reduces security overall.
"preserving security checkpoints in the JDK" suggests just leaving the calls do AccessController.doPrivileged and SecurityManager.checkPermission in place. That amounts to putting a tax on every feature, every JEP, and all ongoing maintenance of the platform. If there is refactoring or a change that forgets to insert a checkPermission somewhere then we have a security issue and everything that goes along with that. No thanks!
I think Martin is right that hooking authorization libraries into low level libraries isn't the right way to do this. Aside from the complexity methods I would add that threads pools or any hand-off between threads will typically break when the context is not carried.
One other point about authorization libraries wanting to hook into low level code is that it's a minefield of potential issues with recursive initialization, stack overflows and some really hard to diagnose issues. JDK-8155659 [1] is one report that comes to mind.
-Alan [1] https://bugs.openjdk.java.net/browse/JDK-8155659
