JDK-8029309 : [macosx] Java Control Panel unable to perform tasks requiring admin privileges
  • Type: Bug
  • Component: deploy
  • Affected Version: 7u40,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: x86
  • Submitted: 2013-11-27
  • Updated: 2017-07-11
  • Resolved: 2016-05-23
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.
8u112 b01Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Some change in 10.9 is preventing the JCP from being able to perform tasks that require admin privileges. This affects both 7u and 8 and seems to be affecting all builds/versions.

I see this following in the system log:
11/27/13 11:25:56.639 AM launchservicesd[96]: Application App:"Java Control Panel" asn:0x0-36036 pid:643 refs=8 @ 0x7f8550527d20 tried to be brought forward, but isn't in fPermittedFrontApps ( ( "LSApplication:0x0-0x3a03a pid=664 "SecurityAgent"")), so denying. : LASSession.cp #1481 SetFrontApplication() q=LSSession 100006/0x186a6 queue
11/27/13 11:25:56.639 AM WindowServer[108]: [cps/setfront] Failed setting the front application to Java Control Panel, psn 0x0-0x36036, securitySessionID=0x186a6, err=-13066
11/27/13 11:25:56.651 AM launchdadd[666]: FAILURE: Job com.oracle.java.deployment.Helper is not loaded in launchd.
11/27/13 11:25:56.651 AM java[643]: Starting job
11/27/13 11:25:56.654 AM java[643]: Job completed

Additionally, the Helper-Tool is having some issue:
11/27/13 11:17:53.554 AM com.apple.launchd[1]: (com.oracle.java.Helper-Tool) Job should be able to exec(3) now.
11/27/13 11:17:53.645 AM com.apple.launchd[1]: (com.oracle.java.Helper-Tool[368]) Exited with code: 1
11/27/13 11:17:53.717 AM com.apple.launchd[1]: (com.oracle.java.Helper-Tool) Throttling respawn: Will start in 10 seconds

This is the core issue that's causing other issues being noticed on 10.9. Those other issues will be linked.
Release Note issue, JDK-8029710, is labeled "release-note=done."

Decide if we need this for 7u

Removed 7-bp, given our work to remove deploy in JDK 7 it would seem this backport is unnecessary.

Removing 9 from affected versions, since it's fixed in 9

I might be able to backport only the user authorization changes I made to get it to work with 10.9+, that might fix this issue without having to rework the plugin disable mechanism too.

The fix for JDK-8027785 was never backported to 8, so it's not surprising this is still happening on 8u101.

Stephen, why this bug must be off 16_03 radar?

I've asked Dev to comment - I will copy you in.

Do we need to remove these tests from JDK8? FYI, SQE needs affected version included the real affected versions; otherwise, our failed tests cannot be map to this known bug. Hence, the test result will show that these tests are new failures. Please advise.

Issue seen with 8u40, 8u45, 8u60, 8u101 - removed all these to take this off the 1603 radar.

This is still reproducible with JDK8u101 b05 on Mac 10.11 Steps: 1. install JDK 8u101 2. open JCP and click on the Update tab 3. uncheck "Check for Updates Automatically" 4. Apply the setting and close the JCP 5. Reopen the JCP to check the setting is still unchecked FAIL: the setting is automatically changed back to checked! affected tests: RULE "Mac/JdkTests/JDK005-013" ExitCode 1 RULE "Mac/JdkTests/JDK005-013-pkg" ExitCode 1 RULE "Mac/JdkTests/JDK005-014" ExitCode 1 RULE "Mac/JdkTests/JDK005-014-pkg" ExitCode 1 RULE "Mac/JreTests/JRE005-013" ExitCode 1 RULE "Mac/JreTests/JRE005-013-pkg" ExitCode 1 RULE "Mac/JreTests/JRE005-014" ExitCode 1 RULE "Mac/JreTests/JRE005-014-pkg" ExitCode 1

I tried both the auto update enable and "Java in browser" enable on 10.10.5 and 10.11.2 and everything worked as expected.

Cannot enable/disable auto update from the JCP on Mac 10.11

Still does not work with 8u60 b12 PIT

re-enabling auto update from the JCP does not work on Mac 10.10 Test bundle: http://jre.us.oracle.com/java/re/jdk/8u40/promoted/all/b27/bundles/macosx-x64/jre-8u40-macosx-x64.dmg

SQE is ok only because dev says it is too risky. This is 1 year old bug that is being deferred 3rd time.

This is now crashing on 10.10 instead of just not working.

affected install tests: RULE Mac/JdkTests/JDK005-013 ExitCode 1 RULE Mac/JdkTests/JDK005-014 ExitCode 1 RULE Mac/JreTests/JRE005-013 ExitCode 1 RULE Mac/JreTests/JRE005-014 ExitCode 1

Release note issue created: JDK-8029710 . Targeted to 8u20

per JDK-8029663, it's possible this may affect re-enabling Java plugin after upgrading.

request to defer to 8u20.

SQE-OK to defer this issue to later releases

downgraded to P3 based on ILW of MHM, probably should be a P4 given the the real impact is probably "low".

I disagree. - "Enterprises" don't generally run OS X, and won't be moving to JDK 8 with the GA release. - Current Oracle plans call for transitioning users to JDK 8 no earlier than the 8u31 (Jan 2014) CPU release Certainly no "enterprise" user will see JDK 8 before 8u20 (or OS X 9 for that matter) - Disable still works, it just is the user-level disable, not a system level disable - The fix is unknown and likely risky as the mechanism for the system level disable is fragile - The failure to disable AU is obvious and disappointing, but causes no actual harm, users can still ignore the update. - A manual work around is possible, but not necessary Given these considerations, this is probably more accurately a P3 bug according to ILW (MHM), which we cannot fix at this point in the release anyway.

I think we should not defer, at least not for 8. - Since disabling java is basically used by enterprise users and their admin needs the system-wide setup to work. - also the fact that check box for disable AU does not work looks like too embarrassing because it's so obvious.

deferral justification: this affects two use cases: disabling java in the browser and disabling checking for updates. - disabling still works, but only on a per-user bases (disabling is done at two levels generally, system and user, only the "system" fails) - checking for updates can not be disables through the JCP, although an OS-level work-around is possible. It's primarily an annoyance as we don't force the update, just alert the user to it's existence.

Any fix for this may depend on getting JDK-8027785 done, but the underlying problem of why the helper tool isn't working is a separate issue.