[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 14:35:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 600:
>> 
>>> 598:                 addExportsOrOpens(opens, true);
>>> 599:             }
>>> 600:             if (Boolean.parseBoolean(mainAttrs.getValue(ENABLE_NATIVE_ACCESS))) {
>> 
>> From a design perspective there are two options here:
>> * `false` means "ignore" (which is what is being implemented here)
>> * `false` means `no native access`.
>> 
>> The latter seems a bit odd - but I'd like to remind the behavior of what happens when `--enable-native-access foo` is specified, and access to restricted method occurs in a module other than `foo`. In that case we throw an exception (e.g. we validate strictly, because a command line option was found).
>> 
>> Jar could do a similar thing:
>> * if no manifest attribute is specified, do the current warning behavior
>> * if attribute is set to `true`, do not warn
>> * if attribute is set to `false`, access to restricted methods in this jar are simply not allowed and must fail with exception
>
> 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 gone ahead and implemented 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?

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

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