From derby-dev-return-70981-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Thu Jul 09 10:55:29 2009 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 25568 invoked from network); 9 Jul 2009 10:55:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Jul 2009 10:55:29 -0000 Received: (qmail 62626 invoked by uid 500); 9 Jul 2009 10:55:39 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 62582 invoked by uid 500); 9 Jul 2009 10:55:39 -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 62574 invoked by uid 99); 9 Jul 2009 10:55:39 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Jul 2009 10:55:39 +0000 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; Thu, 09 Jul 2009 10:55:35 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C78CA234C004 for ; Thu, 9 Jul 2009 03:55:14 -0700 (PDT) Message-ID: <1639458972.1247136914816.JavaMail.jira@brutus> Date: Thu, 9 Jul 2009 03:55:14 -0700 (PDT) From: "Tiago R. Espinha (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-4292) creation of FileInputStream in org.apache.derby.impl.tools.ij.Main not wrapped in privilege block which can cause problems running under SecurityManager In-Reply-To: <858509740.1245959047348.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/DERBY-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tiago R. Espinha updated DERBY-4292: ------------------------------------ Attachment: DERBY-4292-ReproTest.patch I'm attaching the latest patch to this issue. Kathey said: > "...and add a test if the file does not exist..." Is this really necessary? If the file does not exist in the Derby code tree, the SupportFilesSetup will blow up on its own, and if it does exist there, then it is safe to say that it will exist in the extinout folder. If anything, I think we can later on change that ij behavior and make it throw an exception rather than an error message, so that the test fails when the file does not exist. What I'm thinking is that by putting such check on a test, we sort of are masking the problem with ij exiting with status 0 even when the file does not exist. If you think we should have that check anyway, I can easily do it with a new File().exists(). For this patch (just the Repro test) I removed the SecurityManager decorator and added the header to the sql file. The fix remains the same. I'll be running regressions today. > creation of FileInputStream in org.apache.derby.impl.tools.ij.Main not wrapped in privilege block which can cause problems running under SecurityManager > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DERBY-4292 > URL: https://issues.apache.org/jira/browse/DERBY-4292 > Project: Derby > Issue Type: Bug > Components: Tools > Affects Versions: 10.1.3.1, 10.2.2.0, 10.3.2.1, 10.4.2.0, 10.5.1.1, 10.6.0.0 > Reporter: Kathey Marsden > Assignee: Tiago R. Espinha > Attachments: DERBY-4292-Fix.patch, DERBY-4292-Fix.patch, DERBY-4292-Fix.patch, DERBY-4292-ReproTest.patch, DERBY-4292-ReproTest.patch, DERBY-4292-ReproTest.patch, derby4292.zip, derby4292.zip, run.out.debugall > > > org.apache.derby.impl.tools.ij.Main has this code where the call to FileInputStream is not wrapped in a privilege block: > try { > in1 = new FileInputStream(file); > if (in1 != null) { > in1 = new BufferedInputStream(in1, utilMain.BUFFEREDFILESIZE); > in = langUtil.getNewInput(in1); > } > } catch (FileNotFoundException e) { > if (Boolean.getBoolean("ij.searchClassPath")) { > in = langUtil.getNewInput(util.getResourceAsStream(file)); > } > This can cause issues when running under SecurityManager -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.