Fix proposal for bug JDK-8221642

[Alan Bateman]

On 31/01/2022 09:21, Andreas Rosenberg wrote:
> Hi Mandy,
>
> thanks for your comments. Yes, the correct solution is to examine each caller sensitive method. Surely my idea is not
> perfect, as the problem with the ResourceBundle and the bootstrap loader shows. I had the hope that cases like this
> could be solved by implementing a "proxy module object" that could define the correct behavior for such cases (e.g. the
> correct class loader). As far as I understood, the #getModule() call could be used for this.
> At least the class loader issue could probably be solved this way, just as an idea. I'm not very familiar with all the aspects
> of module usage, but this way you had at least a kind of definition in Java, how native code should be seen
> regarding module usage.
>
> My search for "@CallerSensitive" gave me 149 hits in java files, so this is quite a task to examine all. My fear is that
> we my run into another exception in a few month and the fixes for such problems will not arrive in a few days and
> we are facing the same problem again. So a global solution would be preferable. Of course you are worried about
> strange side effects or maybe even security /safety issues, but my hope was that somebody here had the expertise
> to give a good estimation on this.
>
> Regarding permissions: if you don't have any Java stack frames on the stack, that means a native application is using
> Java code as a kind of library (e.g. we use it to read/write MS Excel via Apache POI). In such cases the native app
> must care about that. I could imagine, that there could be use cases that the native app wants to limit permissions
> for a certain Java component (e.g. a WebView that may load data from external sites). In such cases you must
> define permissions for the component, but this should work as soon as there is at least one additional Java stack
> frame on the stack. Right?
Moving this to core-libs-dev as that is where most of the @CS methods are.

There are about 25 API classes in java.base that have @CS methods, most 
of these are reflection or related. So I don't think it's too bad. A 
good starting point out would be a test (maybe based on the existing 
exeCallerAccessTest) to make it easy to exercise each of these methods 
to check their behavior. As Mandy pointed out, there are for 
implications for access control and security to have an intermediate 
frame that reports its class in java.base and is full privileged so care 
is required. An intermediate frame of a class generated into an unnamed 
module may be an alternative to explore as that would limit access to 
public members of public classes that are in packages exported 
unconditionally.

-Alan