[
https://issues.apache.org/jira/browse/DERBY-6352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13964470#comment-13964470
]
Myrna van Lunteren commented on DERBY-6352:
-------------------------------------------
I have made a debug build and am waiting for the results of multi iteration
test runs in an environment where this reproduces more consistently, hopefully
that will tell us what thread (name) is identified as needing the modifyThread
permission.
Until that information is available, I am wondering:
- should we 'support' Derby activity on system threads?
- if not, should we explicitly document this (and where?)
- assuming we find a reasonable explanation for Derby calling interrupt on a
system level thread in the RecoveryAfterBackup test (and even more rare
occurrenes in other tests), would it be acceptable to, when we get this
exception, just check whether we're dealing with a system level thread and if
so, swallow the exception, and only other wise throw the exception?
Something like this (in ContextService.notifyAllActiveThreads):
final Thread fActive = active;
if (cm.setInterrupted(c))
{
// DERBY-6352; in some cases a SecurityException is seen
// demanding an explicit granting of modifyThread
// permission. Just swallow.
try {
AccessController.doPrivileged(
new PrivilegedAction() {
public Object run() {
fActive.interrupt();
return null;
}
});
} catch (java.security.AccessControlException ace) {
// if we're seeing the need for modifyThread exception,
and
// this is a system thread, i.e. no parent thread, then
forget about sending
// an interrupt.
if
(ace.getPermission().toString().indexOf("modifyThread")>0)
{
if(fActive.getThreadGroup().getParent() == null)
continue;
}
else
throw ace;
}
Perhaps this is a bit odd as we'd never see the 'modifyThread' permission
unless it is a system thread?
> Access denied ("java.lang.RuntimePermission" "modifyThread") highly
> intermittent, but e.g. in store.RecoveryAfterBackup test
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6352
> URL: https://issues.apache.org/jira/browse/DERBY-6352
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.9.2.2, 10.10.1.1
> Environment: IBM java 7 Derby version 10.10.1.2 - (1494414)
> Reporter: Kathey Marsden
> Attachments: DERBY-6352_trunk.diff, DERBY-6352_trunk2.diff,
> javacore_1.zip, javacore_2.zip, test-case.diff
>
>
> I got a report of the following intermittent (6/60) exception in
> store.RecoveryAfterBackupTest.
> Exception in thread "main" java.security.AccessControlException: Access
> denied ("java.lang.RuntimePermission" "modifyThread")
> at
> java.security.AccessController.throwACE(AccessController.java:100)
> at
> java.security.AccessController.checkPermission(AccessController.java:174)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at
> java.lang.SecurityManager.checkAccess(SecurityManager.java:676)
> at java.lang.Thread.checkAccess(Thread.java:459)
> at java.lang.Thread.interrupt(Thread.java:588)
> at
> org.apache.derby.iapi.services.context.ContextService$1.run(Unknown Source)
> at
> java.security.AccessController.doPrivileged(AccessController.java:274)
> at
> org.apache.derby.iapi.services.context.ContextService.notifyAllActiveThreads(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
> at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
> at org.apache.derby.jdbc.Driver20.connect(Unknown Source)
> at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown
> Source)
> at java.sql.DriverManager.getConnection(DriverManager.java:571)
> at java.sql.DriverManager.getConnection(DriverManager.java:233)
> at
> org.apache.derbyTesting.functionTests.util.TestUtil.getConnection(TestUtil.java:836)
> at
> org.apache.derbyTesting.functionTests.tests.store.RecoveryAfterBackup.main(RecoveryAfterBackup.java:82)
> modifyThread is a necessary permission if interrupting a thread other than
> the current thread but is not in our policy file for derby.jar.
> The relevant code in ContextService is:
> for (ContextManager cm : allContexts) {
> Thread active = cm.activeThread;
> if (active == me)
> continue;
> if (active == null)
> continue;
> final Thread fActive = active;
> if (cm.setInterrupted(c))
> {
> AccessController.doPrivileged(
> new PrivilegedAction<Void>() {
> public Void run() {
> fActive.interrupt();
> return null;
> }
> });
> }
>
> I am not sure why this has never come up before. Are we expecting in this
> context that fActive is the current thread?
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
