[ 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
