Details
Description
When I enable Java security, I get the following stack trace after allowing permission to 'cxf.xml' and '/WEB-INF/cxf-servlet.xml':
java.security.AccessControlException: access denied (java.io.FilePermission read)
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
java.security.AccessController.checkPermission(AccessController.java:546)
java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
java.lang.SecurityManager.checkRead(SecurityManager.java:871)
java.io.File.exists(File.java:731)
org.apache.cxf.resource.URIResolver.tryFileSystem(URIResolver.java:158)
org.apache.cxf.resource.URIResolver.<init>(URIResolver.java:84)
org.apache.cxf.resource.URIResolver.<init>(URIResolver.java:72)
org.apache.cxf.resource.URIResolver.<init>(URIResolver.java:68)
org.apache.cxf.transport.servlet.CXFServlet.loadAdditionalConfig(CXFServlet.java:148)
org.apache.cxf.transport.servlet.CXFServlet.updateContext(CXFServlet.java:134)
org.apache.cxf.transport.servlet.CXFServlet.loadSpringBus(CXFServlet.java:101)
org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:70)
org.apache.cxf.transport.servlet.AbstractCXFServlet.init(AbstractCXFServlet.java:79)
Looking through the code, I see that CXFServlet uses the URIResolver constructor that calls this("", path). (lines 67-69).
Later in the tryFileSystem method, URIResolver null-checks the baseUriStr (line 154) and then attempts to analyze it. The first File.exists() call triggers the FilePermission exception.
I believe that this can be fixed if the URIResolver constructor calls this(null, path) instead of this("", path). Granting read permission to "" DOES solve the issue as a workaround, but it's less than ideal - security policies are often scrutinized and something like that may raise flags.