Return-Path: Delivered-To: apmail-cxf-issues-archive@www.apache.org Received: (qmail 43495 invoked from network); 4 Mar 2009 22:30:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2009 22:30:17 -0000 Received: (qmail 61676 invoked by uid 500); 4 Mar 2009 22:30:17 -0000 Delivered-To: apmail-cxf-issues-archive@cxf.apache.org Received: (qmail 61662 invoked by uid 500); 4 Mar 2009 22:30:17 -0000 Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cxf.apache.org Delivered-To: mailing list issues@cxf.apache.org Received: (qmail 61651 invoked by uid 99); 4 Mar 2009 22:30:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 14:30:17 -0800 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 22:30:16 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 4BA13234C4A9 for ; Wed, 4 Mar 2009 14:29:56 -0800 (PST) Message-ID: <2118375969.1236205796308.JavaMail.jira@brutus> Date: Wed, 4 Mar 2009 14:29:56 -0800 (PST) From: "Greg Vanore (JIRA)" To: issues@cxf.apache.org Subject: [jira] Updated: (CXF-2087) CXFServlet / URIResolver tries to load file "" (empty file name) In-Reply-To: <1840478277.1236205796079.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/CXF-2087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Greg Vanore updated CXF-2087: ----------------------------- 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.(URIResolver.java:84) org.apache.cxf.resource.URIResolver.(URIResolver.java:72) org.apache.cxf.resource.URIResolver.(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. was: 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.(URIResolver.java:84) org.apache.cxf.resource.URIResolver.(URIResolver.java:72) org.apache.cxf.resource.URIResolver.(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 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. Added line number to description. > CXFServlet / URIResolver tries to load file "" (empty file name) > ---------------------------------------------------------------- > > Key: CXF-2087 > URL: https://issues.apache.org/jira/browse/CXF-2087 > Project: CXF > Issue Type: Bug > Affects Versions: 2.1.4 > Environment: Redhat 5.2; Java 1.6.0u12; Tomcat 6.0.18; CXF 2.1.4 - java security enabled > Reporter: Greg Vanore > Priority: Minor > > 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.(URIResolver.java:84) > org.apache.cxf.resource.URIResolver.(URIResolver.java:72) > org.apache.cxf.resource.URIResolver.(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. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.