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

[Jorn Vernee]

On Tue, 27 Jun 2023 19:50:10 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I had a chat with @AlanBateman. He agrees that seeing "Enable-Native-Access:false" strongly suggests of a deny-like behavior (e.g. access should fail). That said, if we just did that, then it would be possible to have an `--enable-native-access` command line option and a manifest attribute pulling in different directions (e.g. enable vs. disable).
>> 
>> Ideally, we'd like a value-less attribute (e.g. `EnableNativeAccess:`) so that there's no confusion re. true/false. But that is not allowed by the manifest attribute grammar.
>> 
>> The next best thing seems to be `EnableNativeAccess:ALL-UNNAMED`. E.g. we only allow the name of the module we're allowed to enable native access for (the unnamed module). If, in the future, jars will start supporting multiple modules, we can enhance the attribute to accept a comma separated list.
>> 
>> This is slightly less confusing. There's no "deny" state, and no possibilities for the attribute to conflict with the command line option.
>
>> but I'd like to remind the behavior of what happens when --enable-native-access foo is specified
>> if attribute is set to false, access to restricted methods in this jar are simply not allowed and must fail with exception
> 
> Right... I agree here.
> 
> I've spent some time implementing this in the latest commit. This is a bit tricky since we initialize ModuleBootstrap, which holds the 'has enable native access' flag before we process the manifest. I've implemented it as a mutable static that gets lazily set in LauncherHelper.
> 
> WRT the tests. In order to test this I'm launching an executable jar from the class path, which then calls into a module that tries to do the native access.
> 
> But, I'm now starting to wonder whether the `true`/`false` value is really good enough... Does it make sense that a class path jar referencing several modules might want to enable native access for them on a per-module basis? Is an executable jar referencing a module even a case we want to care about at all?

> The next best thing seems to be EnableNativeAccess:ALL-UNNAMED. E.g. we only allow the name of the module we're allowed to enable native access for (the unnamed module). If, in the future, jars will start supporting multiple modules, we can enhance the attribute to accept a comma separated list.

> This is slightly less confusing. There's no "deny" state, and no possibilities for the attribute to conflict with the command line option.

Didn't see these comments. This sounds like a good plan, and I can work on that next.

But, I guess my question still remains: do we want to allow module names for modules outside of the executable jar file? i.e. should it just be a supplement to the --enable-native-access command line option?

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

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