Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 5079 invoked from network); 12 Jul 2006 20:50:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Jul 2006 20:50:35 -0000 Received: (qmail 77413 invoked by uid 500); 12 Jul 2006 20:50:31 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 77378 invoked by uid 500); 12 Jul 2006 20:50:31 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 77340 invoked by uid 99); 12 Jul 2006 20:50:31 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 13:50:30 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [209.237.227.198] (HELO brutus.apache.org) (209.237.227.198) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Jul 2006 13:50:30 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 999894104FD for ; Wed, 12 Jul 2006 20:48:31 +0000 (GMT) Message-ID: <16721361.1152737311626.JavaMail.jira@brutus> Date: Wed, 12 Jul 2006 20:48:31 +0000 (GMT+00:00) From: "A B (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-1507) lang/xmlBinding.java fails with Security Expression In-Reply-To: <19690257.1152737189865.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 X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-1507?page=all ] A B updated DERBY-1507: ----------------------- Attachment: d1507_v1.patch Attaching a simple patch to disable security manager for lang/xmlBinding.java. If anyone has any better alternatives, please let me know. Otherwise, this is a one-line change so if someone could commit, that'd be great. > lang/xmlBinding.java fails with Security Expression > --------------------------------------------------- > > Key: DERBY-1507 > URL: http://issues.apache.org/jira/browse/DERBY-1507 > Project: Derby > Type: Bug > Components: Test > Versions: 10.2.0.0 > Reporter: A B > Assignee: A B > Priority: Minor > Attachments: d1507_v1.patch > > I recently tried to run the lang/xmlBinding.java test and I noticed that the test fails with a Security Exception: > > FAIL: Unexpected exception: > > ERROR 2200L: XMLPARSE operand is not an XML document; see next exception for details. > > java.security.AccessControlException: access denied (java.io.FilePermission {user.dir}/personal.dtd read) > > at java.security.AccessControlContext.checkPermission(AccessControlContext.java(Compiled Code)) > > at java.security.AccessController.checkPermission(AccessController.java(Compiled Code)) > > at java.lang.SecurityManager.checkPermission(SecurityManager.java(Compiled Code)) > > at java.lang.SecurityManager.checkRead(SecurityManager.java(Compiled Code)) > This failure does not show up in the nightlies because the XML tests are not currently run as part of derbyall (see DERBY-563, DERBY-567). > I looked a this a bit and eventually realized that the test itself has all the permission it needs, but Xerces, which Derby uses to parse XML documents, does not. More specifically, and XML document can include a pointer to a schema document, which Xerces will then try to read. In order for that to work the Xerces classes would have to have read permission on user.dir, but we can't add that permission to the derby_tests.policy file because the Xerces classes could be in a Xerces jar anywhere on the system, or they could be included the JVM's own jar (ex. IBM 1.4). And further, when DERBY-567 is fixed the parser that is used could vary from JVM to JVM, so it might not be Xerces but some other parser that needs read permission. > One workaround would be to grant read FilePermission on {user.dir} to "all" (when I did that the test ran cleanly), but it seems to me like that would defeat the purpose of much of the security manager testing. So until a better > option arises, I think the only (or at least, the easiest) option is to just run this specific test with no security manager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira