JDK-8133045 : java.lang.SecurityException: Failed to extract baseline.versions error
  • Type: Bug
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 8u51,9
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2015-08-02
  • Updated: 2017-11-29
  • Resolved: 2016-08-29
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 8 JDK 9
8u131Fixed 9 b135Fixed
Description
FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
Windows 7  (64)

A DESCRIPTION OF THE PROBLEM :
Starting from java 8u51 for java JNLP webstart application - the console is showing the following exception:
Exception in thread "Thread-15" java.lang.SecurityException: Failed to extract baseline.versions
	at com.sun.deploy.util.SecurityBaseline.extractManifest(Unknown Source)
	at com.sun.deploy.util.SecurityBaseline.extractManifests(Unknown Source)
	at com.sun.deploy.util.SecurityBaseline.access$300(Unknown Source)
	at com.sun.deploy.util.SecurityBaseline$1.run(Unknown Source)
	at java.lang.Thread.run(Unknown Source)
Caused by: java.io.FileNotFoundException: C:\Users\baums\AppData\LocalLow\Sun\Java\Deployment\security\baseline.versions (Access is denied)
	at java.io.FileOutputStream.open0(Native Method)
	at java.io.FileOutputStream.open(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	at java.io.FileOutputStream.<init>(Unknown Source)
	... 5 more

This is caused since under the folder C:\Users\baums\AppData\LocalLow\Sun\Java\Deployment\security\, there's already a folder named baseline.versions - hence, a new file with this name cannot be created there.

needless to say the folder was not created manually but rather automatically via the same deployment process of an earlier java version.

deleting the folder manually will resolve the issue and the baseline.versions file will be created successfully with the proper content as written in bug https://bugs.openjdk.java.net/browse/JDK-8077736 

Therefore it is requested that the deployment classes will better handle the situation to avoid the error in creating the file.

REGRESSION.  Last worked in version 8u45


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Delete the "baseline.versions" file from the client machine manually to allow the deploy code to create the "baseline.versions" file at the same location.

not a good workaround as it requires to perform this actions on each client machine.


Comments
Verified on Windows 7 / 9b176.
05-07-2017

UR SQE OK to take it in CPU17_02
28-11-2016

UR SQE OK to defer it from CPU17_01.
28-11-2016

Post SQE sync and discussions - added 17_02 critical watch - once resolved, we will - Add a CPU17_02-critical-request + template SQE/Jitender will review the approvals
19-10-2016

Yes, it's reproduced in 9-ea-b77. However, I had to manually create %USERPROFILE%\AppData\LocalLow\Sun\Java\Deployment\security\baseline.versions folder. Obviously, a file named 'baseline.versions' can't exist if folder 'baseline.versions' already exists. Yet I'm not sure this folder could be created by deploy code. I think the case with folder is pretty easy to handle, however it requires recursive delete of files and subfolders which could result in errors. In addition to this, the permissions on 'Deployment' folder could be messed up so which may result in unusable Java. In this case, JNLP application or applet works fine but Java couldn't update the current security baseline info.
21-08-2015

Alexey to review as Initial Evaluator. If it fails for JDK 9 then I'd like to have Dev look at it (or even take it). Let me know.
20-08-2015

Checked this for JDK 8u51 but couldn't reproduce as reported. Moving this up for dev. team to look at.
05-08-2015