[foreign-memaccess+abi] RFR: 8310659: The jar tool should support allowing access to restricted methods from executable jars [v4]

[Maurizio Cimadamore]

On Wed, 28 Jun 2023 09:31:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The problem here is that the current command line option for native access has a rather sophisticated behavior:
>> * if the option is not present, a warning is emitted
>> * if the option is present, names module M, and access occurs within M, nothing is emitted
>> * if the option is present, names module M, and access occurs outside M, an exception is thrown
>> 
>> This makes enable-native-access non-additive (unlike add-opens). That is, if `Enable-Native-Access:ALL-UNNAMED` is translated into `--enable-native-access=ALL-UNNAMED` well, that means that:
>> 
>> * access to restricted methods from unnamed module is granted
>> * access to restricted methods from a module M that is not unnamed is denied
>> 
>> Now, this patch tries to implement this approach, but I do have worries: effectively, once a manifest specifies the Enable-Native-Access attribute, can the command line still add other modules in the trusted bubble? If yes, that's ok. If no, then we have a problem.
>
> Perhaps, setting an implicit system property in the launcher with the enable-native-access policy (e.g. either warn or deny) would be cleaner. This property will be set by the launcher and read by module bootstrap (like many other properties). This is, I believe, similar to the idea you mentioned above. IMHO that's cleaner in the sense that it's more in the spirit of how already launcher and module bootstrap talk to each other via properties side-channels.

(That said, we still have a problem, in that, by the time we get to LauncherHelper, ModuleBootstrap has already ran. But perhaps we can delay initialization of `HAS_ENABLE_NATIVE_ACCESS_FLAG` on first use, and make the field stable).

-------------

PR Review Comment: https://git.openjdk.org/panama-foreign/pull/843#discussion_r1244966239