[
https://issues.apache.org/jira/browse/LUCENE-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-7502:
----------------------------------
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.
was:
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 it *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.
> Add AccessController.doPrivileged around all calls of Class#getResource() and
> Class#getResourceAsStream()
> ---------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-7502
> URL: https://issues.apache.org/jira/browse/LUCENE-7502
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Uwe Schindler
> Assignee: Uwe Schindler
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
