-
Bug
-
Resolution: Fixed
-
P2
-
None
-
b140
The compatibility impact of this change will be high, because implies() relation between 2 FilePermissions will change, especially if one is on a relative path and the other on an absolute path, or one on a symlink and the other on a target. A FilePermission could be granted in several ways:
- By a policy. For example, a policy file.
- Automatically by a class loader. For example, the FilePermission doc asserts that "Code can always read a file from the same directory it's in (or a subdirectory of that directory); it does not need explicit permission to do so". One can see this behavior implemented in the getPermissions() methods of various ClassLoader implementations, currently including URLClassLoader, BuiltinClassLoader and Loader.
- By a doPrivileged-with-permissions call.
- relates to
-
JDK-8168979 @implNote for invalid FilePermission
-
- Closed
-
-
JDK-8168127 FilePermissionCollection merges incorrectly
-
- Resolved
-
-
JDK-8167646 Better invalid FilePermission
-
- Resolved
-
-
JDK-8170900 Issue with FilePermission::implies for wildcard flag(-)
-
- Closed
-
-
JDK-8177969 Faster FilePermission::implies by avoiding the use of Path::relativize
-
- Closed
-
-
JDK-4141872 FilePermission makes symlinks useless
-
- Closed
-
-
JDK-7066948 non-deterministic canonicalization cache behavior under ${java.home}
-
- Closed
-
-
JDK-8167478 javax/xml/jaxp/unittest/parsers/Bug6341770.java failed with "java.security.AccessControlException: access denied ("java.io.FilePermission" "sko?ice")"
-
- Closed
-
-
JDK-4142973 FilePermission not case insensitive enough under Windows
-
- Closed
-
-
JDK-8207005 Disable the file canonicalization cache by default
-
- Resolved
-