Derby
  1. Derby
  2. DERBY-1152

Failures in sysinfo and sysinfo_withproperties induced by classpath wiring

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.2.1.6
    • Component/s: Test
    • Labels:
      None

      Description

      If you wire your classpath together out of the compiled classtree and the checked-in jars, you get the following error in the sysinfo and sysinfo_withproperties tests. You don't see this error if you run against the built Derby jar files:

      15d14
      < Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read)
      43d41
      < Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read)
      72d69
      < Unable to analyze class path: access denied (java.util.PropertyPermission java.class.path read)
      Test Failed.

        Activity

        Rick Hillegas created issue -
        Rick Hillegas made changes -
        Field Original Value New Value
        Assignee Bryan Pendleton [ bryanpendleton ]
        Hide
        Bryan Pendleton added a comment -

        Myrna van Lunteren wrote:
        > However, sysinfo, accessing java.class.path, lives in both derbytools.jar and derby.jar and also in derbynet.jar. So, I imagine, when running with jars, if derby.jar is first in the classpath, that will be the sysinfo that is being picked up, and so, it can't access java.class.path.

        Thanks Myrna! That is exactly the behavior I see, too.

        Meanwhile, while experimenting with different orders of jars in my
        classpath, I also discovered that the following two lines were added
        to the derby.jar and derbynet.jar, but NOT to the derbytools.jar:

        // BUG DERBY-622 derbynet/sysinfo.java
        permission java.io.FilePermission "$

        {derbyTesting.codedir}${/}*", "read";

        This causes the access to the locale message jars to be inconsistent,
        depending on which jar sysinfo is loaded from.

        So, depending on the details of my classpath, I can create three
        different behaviors for the derbynet/sysinfo.java test:

        1) If I run with jars, with either derby.jar or derbynet.jar first, I
        get the behavior which matches the master files that I submitted:
        - java.class.path cannot be accessed
        - locale message jars can be accessed.

        2) If I run with classes, I get the behavior which Rick & Dan described:
        - java.class.path can be accessed.
        - locale message jars can be accessed.

        3) If I run with jars, but with derbytools.jar first, I get still a
        third behavior:
        - java.class.path can be accessed.
        - locale message jars cannot be accessed.

        Perhaps the easiest way out, at this point, is to make the following changes:
        1) Add

        permission java.util.PropertyPermission "java.class.path", "read";

        for derby.jar, derbynet.jar, and derbytools.jar in derby_tests.policy

        2) Add

        // BUG DERBY-622 derbynet/sysinfo.java
        permission java.io.FilePermission "${derbyTesting.codedir}

        $

        {/}

        *", "read";

        to derbytools.jar in derby_tests.policy

        3) Update the master files to reflect that the sysinfo tests are allowed
        to read both java.class.path AND the locale message jars.

        What do you think?

        thanks,

        bryan

        Show
        Bryan Pendleton added a comment - Myrna van Lunteren wrote: > However, sysinfo, accessing java.class.path, lives in both derbytools.jar and derby.jar and also in derbynet.jar. So, I imagine, when running with jars, if derby.jar is first in the classpath, that will be the sysinfo that is being picked up, and so, it can't access java.class.path. Thanks Myrna! That is exactly the behavior I see, too. Meanwhile, while experimenting with different orders of jars in my classpath, I also discovered that the following two lines were added to the derby.jar and derbynet.jar, but NOT to the derbytools.jar: // BUG DERBY-622 derbynet/sysinfo.java permission java.io.FilePermission "$ {derbyTesting.codedir}${/}*", "read"; This causes the access to the locale message jars to be inconsistent, depending on which jar sysinfo is loaded from. So, depending on the details of my classpath, I can create three different behaviors for the derbynet/sysinfo.java test: 1) If I run with jars, with either derby.jar or derbynet.jar first, I get the behavior which matches the master files that I submitted: - java.class.path cannot be accessed - locale message jars can be accessed. 2) If I run with classes, I get the behavior which Rick & Dan described: - java.class.path can be accessed. - locale message jars can be accessed. 3) If I run with jars, but with derbytools.jar first, I get still a third behavior: - java.class.path can be accessed. - locale message jars cannot be accessed. Perhaps the easiest way out, at this point, is to make the following changes: 1) Add permission java.util.PropertyPermission "java.class.path", "read"; for derby.jar, derbynet.jar, and derbytools.jar in derby_tests.policy 2) Add // BUG DERBY-622 derbynet/sysinfo.java permission java.io.FilePermission "${derbyTesting.codedir} $ {/} *", "read"; to derbytools.jar in derby_tests.policy 3) Update the master files to reflect that the sysinfo tests are allowed to read both java.class.path AND the locale message jars. What do you think? thanks, bryan
        Hide
        Bryan Pendleton added a comment -

        Attached is a proposed patch, derby-1152-looser-policy.diff.

        This patch adds extra lines to derby_tests.policy.

        The idea is that,

        • with respect to reading java.class.path
        • and with respect to accessing the locale message files,
          the sysinfo classes are now granted the same policy, regardless
          of whether the sysinfo classes are loaded from:
        • the classes directory,
        • from derby.jar,
        • from derbynet.jar,
        • or from derbytools.jar.

        Since the two sysinfo tests are no longer denied permission to
        read java.class.path, the patch includes new master files with
        the new expected output.

        Rick, and others who have been experiencing this problem, can you
        please review this patch and see if it resolves your issues with
        the sysinfo tests?

        Dan and Andrew, and others who have been investigating security
        policy issues, can you please consider whether it is OK to
        add these additional lines to derby_tests.policy?

        Show
        Bryan Pendleton added a comment - Attached is a proposed patch, derby-1152-looser-policy.diff. This patch adds extra lines to derby_tests.policy. The idea is that, with respect to reading java.class.path and with respect to accessing the locale message files, the sysinfo classes are now granted the same policy, regardless of whether the sysinfo classes are loaded from: the classes directory, from derby.jar, from derbynet.jar, or from derbytools.jar. Since the two sysinfo tests are no longer denied permission to read java.class.path, the patch includes new master files with the new expected output. Rick, and others who have been experiencing this problem, can you please review this patch and see if it resolves your issues with the sysinfo tests? Dan and Andrew, and others who have been investigating security policy issues, can you please consider whether it is OK to add these additional lines to derby_tests.policy?
        Bryan Pendleton made changes -
        Attachment derby-1152-looser-policy.diff [ 12324622 ]
        Hide
        Rick Hillegas added a comment -

        Thanks, Bryan. This fixes my problem with the sysinfo tests.

        Show
        Rick Hillegas added a comment - Thanks, Bryan. This fixes my problem with the sysinfo tests.
        Hide
        Bryan Pendleton added a comment -

        Thanks Rick, I'm glad to hear it fixes things for you.

        I'm reluctant to commit this change until I get some more feedback about the implications of adding these lines to the policy file, though.

        Show
        Bryan Pendleton added a comment - Thanks Rick, I'm glad to hear it fixes things for you. I'm reluctant to commit this change until I get some more feedback about the implications of adding these lines to the policy file, though.
        Hide
        Bryan Pendleton added a comment -

        Andrew is still working on the relevant functionality as part of DERBY-622. Since this patch directly conflicts with that work (they touch the same policy file lines), resolution of this problem may have to wait until we've determined the outcome of DERBY-622.

        Show
        Bryan Pendleton added a comment - Andrew is still working on the relevant functionality as part of DERBY-622 . Since this patch directly conflicts with that work (they touch the same policy file lines), resolution of this problem may have to wait until we've determined the outcome of DERBY-622 .
        Hide
        Bryan Pendleton added a comment -

        I've committed the 'looser-policy' patch to subversion:
        http://svn.apache.org/viewcvs?rev=391387&view=rev

        Rick, could you please confirm that the sysinfo and sysinfo_withproperties tests are now passing for you, and then close this bug? Thanks.

        Show
        Bryan Pendleton added a comment - I've committed the 'looser-policy' patch to subversion: http://svn.apache.org/viewcvs?rev=391387&view=rev Rick, could you please confirm that the sysinfo and sysinfo_withproperties tests are now passing for you, and then close this bug? Thanks.
        Bryan Pendleton made changes -
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 10.2.0.0 [ 11187 ]
        Hide
        Andrew McIntyre added a comment -

        Sorry for the late reply, but yes, I believe adding these permissions to the test policy is ok. There are only two places in the code we try to get the classpath, sysinfo and the client trace code, both handle security exceptions, and I think it's unlikely that we'll need to get the contents of the classpath elsewhere, but you never know. Maybe we should mark this bug number in the policy file for future reference in case anyone wonders why these permissions were added. I can take care of that as I follow up on DERBY-622.

        Show
        Andrew McIntyre added a comment - Sorry for the late reply, but yes, I believe adding these permissions to the test policy is ok. There are only two places in the code we try to get the classpath, sysinfo and the client trace code, both handle security exceptions, and I think it's unlikely that we'll need to get the contents of the classpath elsewhere, but you never know. Maybe we should mark this bug number in the policy file for future reference in case anyone wonders why these permissions were added. I can take care of that as I follow up on DERBY-622 .
        Rick Hillegas made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Susan Cline added a comment -

        I am running through the examples in the alpha version of the docs for sysinfo.

        On this page: http://db.apache.org/derby/docs/dev/tools/rtoolssysinfo41288.html

        is this statement:

        Use the sysinfo utility to display information about your Java environment and Derby (including version information). To use sysinfo, either derby.jar or derbytools.jar must be in your classpath.

        However, the output when including only derby.jar or derbytools.jar is different. Derbytools.jar output does not include locale information. Am I correct in assuming this bug was supposed to fix the output of sysinfo to be the same for derby.jar and derbytools.jar when only one or the other of those was in the classpath? Or is the behaviour I am seeing correct?

        If it is correct I'll reflect that in the doc review and state that the output should be different if only one or the other is in the classpath.

        Output when only derby.jar is in the classpath:

        C:\derby_src\db-derby-10.2.1.2-bin\demo\databases>set CLASSPATH=C:\derby_src\db-
        derby-10.2.1.2-bin\lib\derby.jar;

        C:\derby_src\db-derby-10.2.1.2-bin\demo\databases>java org.apache.derby.tools.sy
        sinfo
        ------------------ Java Information ------------------
        Java Version: 1.4.2_09
        Java Vendor: Sun Microsystems Inc.
        Java home: C:\JDK\jdk1.4.2_09\jre
        Java classpath: C:\derby_src\db-derby-10.2.1.2-bin\lib\derby.jar;
        OS name: Windows XP
        OS architecture: x86
        OS version: 5.1
        Java user name: slc
        Java user home: C:\Documents and Settings\Administrator
        Java user dir: C:\derby_src\db-derby-10.2.1.2-bin\demo\databases
        java.specification.name: Java Platform API Specification
        java.specification.version: 1.4
        --------- Derby Information --------
        JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
        [C:\derby_src\db-derby-10.2.1.2-bin\lib\derby.jar] 10.2.1.2 beta - (439408)
        ------------------------------------------------------
        ----------------- Locale Information -----------------
        Current Locale : [English/United States [en_US]]
        Found support for locale: [de_DE]
        version: 10.2.1.2 - (439408)
        Found support for locale: [es]
        version: 10.2.1.2 - (439408)
        Found support for locale: [fr]
        version: 10.2.1.2 - (439408)
        Found support for locale: [it]
        version: 10.2.1.2 - (439408)
        Found support for locale: [ja_JP]
        version: 10.2.1.2 - (439408)
        Found support for locale: [ko_KR]
        version: 10.2.1.2 - (439408)
        Found support for locale: [pt_BR]
        version: 10.2.1.2 - (439408)
        Found support for locale: [zh_CN]
        version: 10.2.1.2 - (439408)
        Found support for locale: [zh_TW]
        version: 10.2.1.2 - (439408)
        ------------------------------------------------------

        Output when only derbytools.jar is in the classpath:

        C:\derby_src\db-derby-10.2.1.2-bin\demo\databases>set CLASSPATH=C:\derby_src\db-
        derby-10.2.1.2-bin\lib\derbytools.jar;

        C:\derby_src\db-derby-10.2.1.2-bin\demo\databases>java org.apache.derby.tools.sy
        sinfo
        ------------------ Java Information ------------------
        Java Version: 1.4.2_09
        Java Vendor: Sun Microsystems Inc.
        Java home: C:\JDK\jdk1.4.2_09\jre
        Java classpath: C:\derby_src\db-derby-10.2.1.2-bin\lib\derbytools.jar;
        OS name: Windows XP
        OS architecture: x86
        OS version: 5.1
        Java user name: slc
        Java user home: C:\Documents and Settings\Administrator
        Java user dir: C:\derby_src\db-derby-10.2.1.2-bin\demo\databases
        java.specification.name: Java Platform API Specification
        java.specification.version: 1.4
        --------- Derby Information --------
        JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
        [C:\derby_src\db-derby-10.2.1.2-bin\lib\derbytools.jar] 10.2.1.2 beta - (439408)

        ------------------------------------------------------
        ----------------- Locale Information -----------------
        ------------------------------------------------------

        Show
        Susan Cline added a comment - I am running through the examples in the alpha version of the docs for sysinfo. On this page: http://db.apache.org/derby/docs/dev/tools/rtoolssysinfo41288.html is this statement: Use the sysinfo utility to display information about your Java environment and Derby (including version information). To use sysinfo, either derby.jar or derbytools.jar must be in your classpath. However, the output when including only derby.jar or derbytools.jar is different. Derbytools.jar output does not include locale information. Am I correct in assuming this bug was supposed to fix the output of sysinfo to be the same for derby.jar and derbytools.jar when only one or the other of those was in the classpath? Or is the behaviour I am seeing correct? If it is correct I'll reflect that in the doc review and state that the output should be different if only one or the other is in the classpath. Output when only derby.jar is in the classpath: C:\derby_src\db-derby-10.2.1.2-bin\demo\databases>set CLASSPATH=C:\derby_src\db- derby-10.2.1.2-bin\lib\derby.jar; C:\derby_src\db-derby-10.2.1.2-bin\demo\databases>java org.apache.derby.tools.sy sinfo ------------------ Java Information ------------------ Java Version: 1.4.2_09 Java Vendor: Sun Microsystems Inc. Java home: C:\JDK\jdk1.4.2_09\jre Java classpath: C:\derby_src\db-derby-10.2.1.2-bin\lib\derby.jar; OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: slc Java user home: C:\Documents and Settings\Administrator Java user dir: C:\derby_src\db-derby-10.2.1.2-bin\demo\databases java.specification.name: Java Platform API Specification java.specification.version: 1.4 --------- Derby Information -------- JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\derby_src\db-derby-10.2.1.2-bin\lib\derby.jar] 10.2.1.2 beta - (439408) ------------------------------------------------------ ----------------- Locale Information ----------------- Current Locale : [English/United States [en_US] ] Found support for locale: [de_DE] version: 10.2.1.2 - (439408) Found support for locale: [es] version: 10.2.1.2 - (439408) Found support for locale: [fr] version: 10.2.1.2 - (439408) Found support for locale: [it] version: 10.2.1.2 - (439408) Found support for locale: [ja_JP] version: 10.2.1.2 - (439408) Found support for locale: [ko_KR] version: 10.2.1.2 - (439408) Found support for locale: [pt_BR] version: 10.2.1.2 - (439408) Found support for locale: [zh_CN] version: 10.2.1.2 - (439408) Found support for locale: [zh_TW] version: 10.2.1.2 - (439408) ------------------------------------------------------ Output when only derbytools.jar is in the classpath: C:\derby_src\db-derby-10.2.1.2-bin\demo\databases>set CLASSPATH=C:\derby_src\db- derby-10.2.1.2-bin\lib\derbytools.jar; C:\derby_src\db-derby-10.2.1.2-bin\demo\databases>java org.apache.derby.tools.sy sinfo ------------------ Java Information ------------------ Java Version: 1.4.2_09 Java Vendor: Sun Microsystems Inc. Java home: C:\JDK\jdk1.4.2_09\jre Java classpath: C:\derby_src\db-derby-10.2.1.2-bin\lib\derbytools.jar; OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: slc Java user home: C:\Documents and Settings\Administrator Java user dir: C:\derby_src\db-derby-10.2.1.2-bin\demo\databases java.specification.name: Java Platform API Specification java.specification.version: 1.4 --------- Derby Information -------- JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\derby_src\db-derby-10.2.1.2-bin\lib\derbytools.jar] 10.2.1.2 beta - (439408) ------------------------------------------------------ ----------------- Locale Information ----------------- ------------------------------------------------------
        Hide
        Bryan Pendleton added a comment -

        Hi Susan, thanks for having a look at this!

        I believe that the output is correct, and reflects an important difference between derby.jar
        and derbytools.jar: derby.jar has an entry in its Manifest file which automatically loads all
        of the locale-specific properties jars, whereas derbytools.jar doesnt.

        That is, when your classpath specifies only derby.jar, but you also have the local jars
        in the same physical directory as derby.jar, the Java class loader reads the Manifest
        classpath entry and automatically loads the locale jars when it loads derby.jar.

        But derbytools.jar, which omits that special Manifest entry, does not automatically load
        those Manifest jars.

        Sysinfo, in my opinion, is faithfully reporting the actual environment as it finds it, and that
        environment, with respect to the locale jars in the classpath, is indeed different in this case.

        Show
        Bryan Pendleton added a comment - Hi Susan, thanks for having a look at this! I believe that the output is correct, and reflects an important difference between derby.jar and derbytools.jar: derby.jar has an entry in its Manifest file which automatically loads all of the locale-specific properties jars, whereas derbytools.jar doesnt. That is, when your classpath specifies only derby.jar, but you also have the local jars in the same physical directory as derby.jar, the Java class loader reads the Manifest classpath entry and automatically loads the locale jars when it loads derby.jar. But derbytools.jar, which omits that special Manifest entry, does not automatically load those Manifest jars. Sysinfo, in my opinion, is faithfully reporting the actual environment as it finds it, and that environment, with respect to the locale jars in the classpath, is indeed different in this case.
        Hide
        Susan Cline added a comment -

        Hi Bryan,

        Thanks for your response. I'll make an addition to the documentation to change it accordingly then.

        Susan

        Show
        Susan Cline added a comment - Hi Bryan, Thanks for your response. I'll make an addition to the documentation to change it accordingly then. Susan
        Gavin made changes -
        Workflow jira [ 12352507 ] Default workflow, editable Closed status [ 12797868 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open Resolved Resolved
        8d 52m 1 Bryan Pendleton 05/Apr/06 04:02
        Resolved Resolved Closed Closed
        97d 21h 28m 1 Rick Hillegas 12/Jul/06 01:30

          People

          • Assignee:
            Bryan Pendleton
            Reporter:
            Rick Hillegas
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development