Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
-
None
-
New
Description
After ongoing discussions on the mailing list about recent breakage of Java 9 with the security manager and a clarifying statement in the javadocs of the above mentioned methods, we should wrap all Class#getResource() calls (especially in analyzers when loading stopword lists and similar stuff) inside AccessController.doPrivileged(lambda). FYI see this thread: http://www.gossamer-threads.com/lists/lucene/java-dev/329236
The reason for this is: The lookup of the JAR's own resources must be done in the security context of the JAR file calling the lookup. Without the doPrivileged, the resource lookup will fail if there is no separate permission added that allows access to the JAR file (this is why we have the special "hack" in our test policy file). Code is only allowed to load its own resources by default, but when doing this it must do this in its own context, so it requires AccessController.doPrivileged. Recent Java 9 versions have updated its documentation to clearly state this (http://download.java.net/java/jigsaw/docs/api/java/lang/Class.html#getResource-java.lang.String-): "Returns: A URL object; null if no resource with this name is found, the resource cannot be located by a URL, the resource is in a package that is not exported-private to the caller module, or access to the resource is denied by the security manager." This is far from ideal, but the broken "returns null" is there from beginning of Java times, so it cannot throw NoSuchFileException or SecurityException. Because of this many third party libraries miss to do this!
This also affects SPIClassIterator for loading our codecs.
Attachments
Issue Links
- is related to
-
LUCENE-7507 Update morfologik-stemming to version 2.1.1
-
- Resolved
-