db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-1758) Enable xmlSuite to run as part of derbyall for JVMs that embed the required external jars.
Date Wed, 22 Nov 2006 01:07:03 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1758?page=all ]

A B updated DERBY-1758:
-----------------------

    Attachment: d1758_newSecMgr_doNotCommit.patch

While trying to add lang/XMLBindingTest.java to a JUnit suite so that it can run as part of
suites.All, I ran into a problem where the test setup fails because the JAXP parser does not
have permissions to read the DTD file that is used for inserting test data.

Note that this isn't a problem when running the test alone because when it runs standalone,
the "setup" work happens *before* the security manager is installed.  When the test is run
as part of a suite, though, a security manager is installed for any tests that run prior to
XMLBindingTest, and that security manager is not "uninstalled" after those tests.  Then, since
the lingering security manager does not give the necessary permissions to JAXP, the binding
test fails during setup.

This security problem was also an issue for the old binding test, lang/xmlBinding.java.  In
that case the problem was solved by creating a policy file with specific permissions to allow
"everything" to read the DTD file.  That permission was then automatically "merged" into the
security manager's policy as part of the old harness setup, thereby allowing the test to run
without error.

So I made some changes to the JUnit security manager setup to allow a test to append permissions
to a policy file and to then install a security manager with those permissions.  However,
when I try to run XMLBindingTest.java as part of a JUnit suite, the new permissions are never
picked up.

I did some tracing in the JUnit setup classes and I can verify that the code to "uninstall"
a security manager and install a new manager that uses the modified policy is in fact being
executed.  However, it looks like the new SecurityManager() is never actually being enforced.
 Or put another way, it looks like the security policy that takes effect is always the *first*
one to be assigned in the JVM; subsequent attempts to set the System security manager to non-null
values will *re-enable* the security manager, but will not alter its policy.

Note, though, that attempts to UN-install the security manager (by calling System.setSecurityManager(null))
*do* work.  But when we try try to call setSecurityManager() with a non-null value (namely,
"new SecurityManager()"), the policy that it implements is always the first policy that was
successfully applied for the JVM; if the "java.security.policy" property is pointing to some
other (new) policy file, it is ignored.

At least, this is what I've come to conclude based on my understanding of the security manager
setup code.

In order to get the binding test to work as part of a suite I can just uninstall the security
manager altogether--that works fine. However, that seems a bit like cheating to me.  And to
be honest, I think that we *should* be able to change the security manager to use a new policy--or
at least, that has been my impression based on the code comments.

So my question, then, is this: does anyone know if I have to do something special to get the
test to install a Security Manager that implements a different policy file than one that has
previously been installed?  I've spent a lot of time on this but have come up empty-handed.

I'm attaching a patch, d1758_newSecMgr_doNotCommit.patch with the test setup changes that
I've made.  If there are any problems (glaring or otherwise) with my approach that might be
leading to this inability to alter security policy, I would be grateful to anyone who could
point them out...  

Note the patch includes all of the changes that I've made to add XMLBindingTest.java to a
new  XML JUnit suite.  I'm hoping anyone who looks at it can just ignore the test-specific
changes and focus on the security-related ones...

> Enable xmlSuite to run as part of derbyall for JVMs that embed the required external
jars.
> ------------------------------------------------------------------------------------------
>
>                 Key: DERBY-1758
>                 URL: http://issues.apache.org/jira/browse/DERBY-1758
>             Project: Derby
>          Issue Type: Task
>          Components: Test
>    Affects Versions: 10.2.1.6, 10.3.0.0, 10.2.2.0
>            Reporter: A B
>         Assigned To: A B
>         Attachments: d1758_followup_v1.patch, d1758_newJUnitTests_v1.patch, d1758_newJUnitTests_v1.stat,
d1758_newJUnitTests_v2.patch, d1758_newSecMgr_doNotCommit.patch, d1758_newXBindTest_v1.patch,
d1758_remove_xgen_v1.patch, d1758_remove_xgen_v1.stat
>
>
> Due to the fact the XML support in Derby has external dependencies on Apache Xalan and
a JAXP parser (such as, but not limited to, Apache Xerces), the tests for XML, which are all
included in "xmlSuite", are not currently run as part of derbyall.
> Changes for DERBY-688 (and DERBY-567 indirectly) have now made it so that JVMs which
have Apache Xalan and a JAXP parser embedded in them can run the XML tests without requiring
additional jars, assuming that the embedded version of Xalan is at least the minimum version
required by Derby (which is currently 2.5).
> So given that, the xmlSuite should be enabled as part of derbyall for any JVMs that are
capable of running them.  Currently, this appears to mean only ibm142 and ibm15.
> Per comments in DERBY-688, enabling the XML suite could include the following tasks:
>   1. Enable the suite to run as part of derbyall but ONLY for JVMs that
>      embed the required Xalan/JAXP classes.
>   2. Resolve the following diff in lang/xmlBinding.java that occurs on
>      some platforms (ex. Linux):
>     < Inserted roughly 40k of data.
>     10 del
>     < Inserted roughly 40k of data.
>     10a9,10
>     > Inserted roughly 39k of data.
>     > Inserted roughly 37k of data.
>     21 del
>     < 1, [ roughly 40k ]
>     22 del
>     < 2, [ roughly 40k ]
>     22a21,22
>     > 1, [ roughly 39k ]
>     > 2, [ roughly 37k ]
>   3. Add new tests to verify Derby behavior when XML classes are
>     not present.
> Note that #3 may turn out to be its own Jira issue; the first two, however, should both
be addressed as part of this issue since the xmlSuite will not run (and pass) on all platforms
if either 1 or 2 is not addressed.

-- 
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

        

Mime
View raw message