Request - Preparation for removal of SecurityManager

Alan Bateman Alan.Bateman at
Wed Oct 26 13:07:16 UTC 2022

On 26/10/2022 09:02, Peter Firmstone wrote:
> :
> That's correct, however some parts will bit rot faster than others, 
> historically some parts of the JDK are very slow to change, unless 
> someone comes through deliberately removing them, which I would hope 
> not, but I realise that new methods and classes might open new code 
> paths that don't invoke them.

It's too early to say whether permission checks will be removed in a 
single releases or staggered or several releases but I wouldn't expect 
dead code to hang around for too long.

> :
> What would make a significant difference is returning non null 
> ProtectionDomain's for JDK modules, so we can reduce the size of the 
> trusted computing base, to make our job smaller, hopefully that will 
> allow focusing on placing authorization checks on the low level access 
> to file systems and networks, which are our main concerns.
The PD should not be null, maybe you mean the CodeSource? I think we 
exchanged mail about this before and it might be generally useful to 
have that. It would mean working through some issues related to patching.

> :
> Do you think that tighter module boundaries will negate the need for 
> RuntimePermission accessClassInPackage.* below?
This is only needed when running with a SM.


More information about the security-dev mailing list