JDK-4215035 : standard extensions path is hard-coded in default system policy file
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 1.2.0,1.3.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 1999-02-25
  • Updated: 2014-07-01
  • Resolved: 2001-06-15
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.
Other
1.4.0 beta2Fixed
Related Reports
Duplicate :  
JDK-4236952 - java.policy fix for 4215035 assumed java.ext.dirs expansion was correct
Relates :  
JDK-4993819 - standard extensions path is hard-coded in default system policy file
Relates :  
JDK-8040059 - Change default policy for extensions to no permission
Description
The default system policy file (in jre/lib/security/java.policy)
grants all permissions to standard extensions, as follows:

grant codeBase "file:${java.home}/lib/ext/*" {
        permission java.security.AllPermission;
};

This uses a hardcoded path to the extensions directory, which users could change
by setting the "java.ext.dirs" system property.

Therefore, the above "grant" statement should be changed to:

grant codeBase "file:${java.ext.dirs}/*" {
        permission java.security.AllPermission;
};
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: merlin-beta2 INTEGRATED IN: merlin-beta2
14-06-2004
EVALUATION jan.luehe@Eng 1999-03-02 needs to be fixed bradford.wetmore@EBay 1999-05-07 Problem is fixed, regression tests written, awaiting codereview. bradford.wetmore@eng 1999-05-25 It was not as simple as original thought. The following was copied from 4236952. ====================== During the fix for 4215035, I assumed that the the java.ext.dirs/* would be expanded correctly, but it is not. This needs to be fixed. The following shows the problem. /* * This is a trivial file to grab the security manager, grab a * permission object, then try to check the resulting permission. */ import java.io.*; import java.security.*; public class Ext_AllPolicy { public static void main (String[] args) { FilePermission mine = new FilePermission("/tmp/bar", "read"); SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(mine); } } } 206 15:48 javac Ext_AllPolicy.java 208 15:48 jar -cvf brad.jar Ext_AllPolicy.class 209 15:48 mv brad.jar /tmp 217 15:51 java -Djava.security.manager -Djava.ext.dirs="/tmp" Ext_AllPolicy This works as expected. 218 15:51 java -Djava.security.manager -Djava.ext.dirs=".:/tmp" Ext_AllPolicy This does not, the only difference is the java.ext.dirs: java -Djava.security.manager -Djava.ext.dirs=".:/tmp" Ext_AllPolicy Exception in thread "main" java.security.AccessControlException: access denied (java.io.FilePermission /tmp/bar read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java, Compiled Code) at java.security.AccessController.checkPermission(AccessController.java, Compiled Code) at java.lang.SecurityManager.checkPermission(SecurityManager.java, Compiled Code) at Ext_AllPolicy.main(Ext_AllPolicy.java, Compiled Code) ====================== The problem is that the string was expanded into the following: ".:/tmp/*" Which of course is jibberish. This needs to be fixed properly. I am backing out the original fix, until the proper one can be put into place. bradford.wetmore@eng 1999-06-07 In addition to the normal entry in the default policy file, in PolicyFile.java, there is a static entry that will also need to be updated. See src/share/classes/sun/security/provider/PolicyFile.java: initStaticPolicy() try { String extdir = PropertyExpander.expand("file:${java.home}/lib/ext/*"); bradford.wetmore@eng 1999-06-24 I was wrong about the PolicyFile entry above, this does something completely different. Basically, the fix is to expand ${}-style entries. Parse the replacement, look for separators. Then create an array with the completely parsed entries, pass back to parseGrantEntry in PolicyParser.java, then let parseGrantEntry return back a GrantEntry[] instead of a single entry. Then in the calling code, traverse the array, adding to the object each entry in the array. This will need to be written up in the documentation, as expanding the ${} isn't a normal operation. the alternative is to have a new keyword, such as "codebases." charlie.lai@Eng 2001-06-12 the fix is to allow the following to be specified: grant codebase "${java.ext.dirs}" { perms... }; then policy parser will parse java.ext.dirs into its components and create separate grant entries for each component with the configured permissions. the default policy remains the same (it has the hardcoded grant entry). this allows the admin to change the value to ${java.ext.dirs}. if java.ext.dirs is not defined at runtime, then the whole entry will be ignored.
11-06-2004
WORK AROUND Work around is the same as the suggested fix.
11-06-2004
SUGGESTED FIX "grant" statement should be changed to: grant codeBase "file:${java.ext.dirs}/*" { permission java.security.AllPermission; };
11-06-2004