Bug ID: JDK-8029309 [macosx] Java Control Panel unable to perform tasks requiring admin privileges

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

Versions (Unresolved/Resolved/Fixed)

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
8u112 b01Fixed

Related Reports

Duplicate :	JDK-8040758 - Java for Mac will not disable automatic updates on OS X 10.9 or later
Duplicate :	JDK-8179620 - [macosx] Java control panel setting to disable automatic updates does not work.
Duplicate :	JDK-8165483 - Checkbox for disabling update checking is not respected in MAC
Duplicate :	JDK-8054879 - Java Control Panel crashes on Mac 10.10 Preview
Duplicate :	JDK-8003580 - (Mac) [INTERMITTENT ISSUE] Java is only disabled for current user even if the correct Admin credential is provided on Mac.
Duplicate :	JDK-8033808 - Cannot enable Java in Browser
Duplicate :	JDK-8038121 - Java is still Enabled for user O1, and the applications in step 5 and step 6 can't be blocked.
Duplicate :	JDK-8150706 - Java for MAC will not disable automatic updates in MAC OS X 10.11.2
Relates :	JDK-8150706 - Java for MAC will not disable automatic updates in MAC OS X 10.11.2
Relates :	JDK-8028761 - (mac) Fix failed for JDK-7175776 Can not save disabling "Check for Updates Automatically".

Description

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.

Comments

Release Note issue, JDK-8029710, is labeled "release-note=done."
17-02-2017
Decide if we need this for 7u
19-08-2016
Removed 7-bp, given our work to remove deploy in JDK 7 it would seem this backport is unnecessary.
20-06-2016
Removing 9 from affected versions, since it's fixed in 9
11-05-2016
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.
10-05-2016
The fix for JDK-8027785 was never backported to 8, so it's not surprising this is still happening on 8u101.
10-05-2016
Stephen, why this bug must be off 16_03 radar?
28-04-2016
I've asked Dev to comment - I will copy you in.
28-04-2016
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.
28-04-2016
Issue seen with 8u40, 8u45, 8u60, 8u101 - removed all these to take this off the 1603 radar.
28-04-2016
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
28-04-2016
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.
19-01-2016
Cannot enable/disable auto update from the JCP on Mac 10.11
17-09-2015
Still does not work with 8u60 b12 PIT
22-04-2015
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
15-03-2015
SQE is ok only because dev says it is too risky. This is 1 year old bug that is being deferred 3rd time.
01-12-2014
This is now crashing on 10.10 instead of just not working.
17-10-2014
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
23-09-2014
Release note issue created: JDK-8029710 . Targeted to 8u20
06-12-2013
per JDK-8029663, it's possible this may affect re-enabling Java plugin after upgrading.
06-12-2013
request to defer to 8u20.
05-12-2013
SQE-OK to defer this issue to later releases
05-12-2013
downgraded to P3 based on ILW of MHM, probably should be a P4 given the the real impact is probably "low".
05-12-2013
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.
05-12-2013
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.
05-12-2013
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.
03-12-2013
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.
27-11-2013