• Type: Bug
• Component: security-libs
• Sub-Component: java.security
• Affected Version: 8

• Priority: P2
• Status: Closed
• Resolution: Fixed
• OS: generic
• CPU: generic

• Submitted: 2012-10-23
• Updated: 2017-06-14
• Resolved: 2013-08-02

JDK 8
8 b103Fixed

Release notes suggested text. Affects Java SE. The java.security.SecurityPermission "insertProvider.{provider name}" target name is discouraged from further use because it is possible to circumvent the name restrictions by overriding the java.security.Provider.getName method. Also, there is an equivalent level of risk associated with granting code permission to insert a provider with a specific name, or any name it chooses. Users should use the new "insertProvider" target name instead. Compatibility with existing policy files has been preserved, as both the old and new permission will be checked by the Security.addProvider and insertProviderAt methods. 06-08-2013 The Security.addProvider and insertProviderAt methods throw a SecurityException if a security manager is enabled and the SecurityPermission "insertProvider.{provider name} (where provider name is the name of the provider passed to the methods) has not been granted. However, this check can be worked around by the caller because the getName method of Provider can be overridden. For example, a programmer could override getName to return different results. This would allow code that had been granted permission to install a provider with a specific name to install it with any name it chooses. It turns out that nothing bad can come of this, because there is an equivalent level of risk associated with granting code permission to insert a provider with a specific name, or any name it chooses. This is a flaw in the API that we want to fix going forward in JDK 8. The proposed solution is to add a new "insertProvider" SecurityPermission target name, and discourage use of the old permission. (Unfortunately you can't officially deprecate a permission target name). Also, the Security.addProvider and insertProviderAt methods will be changed to first check if the "insertProvider" SecurityPermission has been granted, and failing that, then check if the legacy "insertProvider.{provider name}" permission has been granted. This preserves compatibility with existing policy files by still checking the old permission. 24-07-2013