JDK-8153077 : Allow -XaddExports be specified via the java-vm-args attribute
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: webstart
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-03-30
  • Updated: 2017-01-19
  • Resolved: 2016-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b124Fixed
Related Reports
Relates :  
JDK-8172986 - Allow --add-opens option for JNLP signed all permission apps
Relates :  
JDK-8162110 - Update list of secure properties and secure vm args
Relates :  
JDK-8154426 - Allow the equivalent of -XaddExports in the manifest of an application JAR file
Relates :  
JDK-8136930 - Simplify use of module-system options by custom launchers
Description
JNLP applications that use JDK-internal APIs can't currently use -XaddExports to break encapsulation.

We should investigate whether -XaddExports can be white listed and so be allowed in the java-vm-args attribute.
Comments
revised approach is simpler and is as follows: 1.) -XaddExports: will be added as a secure vm-arg prefix in native list, and in secureSignedVmPrefixes list in java list in Config. Config.isSecureVmArg(arg) will return true if the arg starts with a prefix in either list (secureVmPrefix or secureSignedVmPrefix) 2.) When launching an application or an applet, we will check if the vm-args (used from selected JREDesc when launching a jnlp app, or from java_arguments param when launching a non-jnlp applet) contains any of the "secureSignedVmPrefix" args, and if the app is running with sandbox permissions, a SecurityException will be thrown. (in the jnlp case, an app with any jnlp file not requesting all-permissions will be blocked if selected JREDesc contains any vm-args starting with any secureSignedVmPrefix. In the non-jnlp case, an app whose main class is not granted all-permissions will be blocked). Crucible review: https://java.se.oracle.com/code/cru/CR-JDK9CLIENT-195 testcases: 1) negative tests: 1.1.) non-jnlp applet in browser in sandbox throwing exception: http://oklahoma.us.oracle.com/www/tests/dialogs/html/applet-sandbox.html 1.2.) jnlp applet in browser in sandbox throwing exception: http://oklahoma.us.oracle.com/www/tests/dialogs/html/ 1.3.) jnlp applet in webstart in sandbox throwing exception: http://oklahoma.us.oracle.com/www/tests/dialogs/jnlp/HelloWorld-sandbox.jnlp 1.4.) jnlp awt application in webstart in sandbox throwing exception: http://oklahoma.us.oracle.com/www/tests/dialogs/jnlp/awt9-sandbox.jnlp 1.5.) jnlp fx app in webstart in sandbox throwing exception: 2) positive tests: 2.1) non-jnlp all-permissions applet in browser: http://oklahoma.us.oracle.com/www/tests/dialogs/html/applet-allpermissions.html 2.2) jnlp all-permissions applet in browser: http://oklahoma.us.oracle.com/www/tests/dialogs/html/awt9.html 2.3) javafx all-permissions app in browser: http://oklahoma.us.oracle.com/www/tests/dialogs/html/jfx9.html 2.4) jnlp awt all-permissions application in webstart: http://oklahoma.us.oracle.com/www/tests/dialogs/html/awt9.html 2.5) jnlp awt all-permissions applet in webstart: http://oklahoma.us.oracle.com/www/tests/dialogs/html/applet-allpermissions.html 2.6) jnlp javafx all-permissions app in browser: http://oklahoma.us.oracle.com/www/tests/dialogs/html/jfx9.html note: in all positive cases except 2.1 you can click the show dialogs button and see all the UIToolkit dialogs. to do this it needs all the -XaddExports: arg to get to the deploy code that shows the dialogs. In case 2.1, it is not jnlp, so the code will just reply "cannot find LaunchDesc", but even that verifies that the code was able to access com.sun.javaws.jnl.LaunchDesc. Without the -XaddExports args, you would just get Exceptions trying to access the deploy classes.
13-05-2016
OK - it seems not too difficult to consider a list of "Special VmArgs" (or as in this case "Special VmArg Prefixes") secure - only when all jnlp files are requesting all-permissions (code requesting all-permissions will not run unless it is granted all-permission) It is not so easy for non-jnlp applets. We don't know ahead of time for non-jnlp applets if these will be sandboxed code, we only know the status of the main jar (or main class) by the time we decide the vm-args to use on a relaunch. As I see it we have two options: 1.) Only allow -XaddExports: as a secure vm-arg prefix when using JNLP (Don't allow at all in non-jnlp applets to use -XaddExports:). 2.) Allow -XaddExports; in a non-jnlp applet whenever the main jar is signed and accepted by user (or DRS) to run with all-permissions.
06-05-2016
I don't think requiring -XaddExports to be in a signed jnlp file addresses the problem at all. That is the current state (and yet this bug was filed), requiring developers to sign the jnlp file is not possible for many real applications that generate the jnlp file on the fly. I will investigate implementing the new case, where a new set of VM args is allowed only for applications granted all-permissions.
02-05-2016
The original request was to whitelist this arg, to allow it to be used as a secure property in all cases. The discussion above says it is not secure, and should only be used by apps with code that has been granted all-permissions. Since the jnlp file (unless using signed jnlp file) is not within the scope of the signing of a signed app, we normally do not consider signing here. Existing code has only two cases, secure vm-args which can be used by anyone and insecure vm-args, which will only be used if they come from a signed jnlp file. What the above two comments are suggesting is that this is a third case , a somewhat secure vm-arg, that can be used by applications that are granted all-permissions, regardless of the source of the arg (whether if comes from a signed or unsigned jnlp file.)
29-04-2016