Re: Is RuntimePermission.accessClassInPackage now redundant?

[Mike Hearn]

Thanks. Those changes sound unlikely to cause compatibility issues. On the
other hand, if there's nothing motivating such a change then perhaps best
to let sleeping dogs lie. It's sufficient to know that new modules don't
need them.

I was exploring because the recent supply chain/package management attacks
on large tech firms make the intersection of JPMS and Java sandboxing look
increasingly relevant and interesting.

Re: Is RuntimePermission.accessClassInPackage now redundant?

[Alan Bateman]

On 15/02/2021 19:45, Mike Hearn wrote:

Hello,

I was reviewing the default security policy and noticed quite a few modules
are given accessClassInPackage permissions to e.g. packages in the sun.*
hierarchy. Are the SecurityManager/ClassLoader based package control still
needed now the module system has a built-in equivalent? I wasn't fully sure
if this is some sort of tech debt waiting to be cleaned up, or if these
permissions still have a role to play in the post-Jigsaw world?
This is a good observation. There was a lengthy discussion about this 
here in 2017. The summary is that we want the package access check to go 
away. It will mean a few subtle behavioral changes. In particular, 
IllegalAccessError may be thrown for cases where SecurityException is 
thrown today (assume running with a SM). It may also change the point 
where an exception is thrown due to verification triggering class 
loading and a package access check.


-Alan