[
https://issues.apache.org/jira/browse/DERBY-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kathey Marsden updated DERBY-5582:
----------------------------------
Summary: Access denied (java.lang.RuntimePermission modifyThreadGroup) in
IndexStatisticsDaemonImpl.schedule() (was: Access denied
(java.lang.RuntimePermission modifyThreadGroup) in
IndexStatisticsDaemonImpl.schedule(Unknown Source) )
I was incorrect in my early assessment that public Thread(Runnable target,
String name)
should not throw a Security exception.
I got this comment from the user which I think is a fair assessment. Derby
should use the derby group for our thread. I gave them a test build with the
change Kristian recommended and will see if that resolves the issue. I am
having a bit of trouble getting a stand alone test case, but will keep working
on that.
According to the javadocs for Thread, that method effectively calls the
following signature with TG=null
public Thread(ThreadGroup group,
Runnable target,
String name)
For which the javadocs say:
"If group is null and there is a security manager, the group is determined by
the security manager's getThreadGroup method. If group is null and there is not
a security manager, or the security manager's getThreadGroup method returns
null, the group is set to be the same ThreadGroup as the thread that is
creating the new thread.
If there is a security manager, its checkAccess method is called with the
ThreadGroup as its argument."
Based on the javadocs for the signature called, group is null, thus the group
is determined by the security manager's getThreadGroup method. Since our sec
mgr doesn't override the base sec mgr's getThreadGroup(), it's behavior is
dependent on that impl. If it returned null, the group would then be that of
the calling thread,
which based on the stack is a worker thread from the thread pool executing an
ejb call. Since there is a sec mgr, checkAccess is called. Since the thread
is our ejb thread, not a Derby thread, I'm guessing that
IndexStatisticsDaemonImpl.schedule() call doesn't have perms to add a new
Thread to the ThreadGroup? So maybe the call
to new up the statistics thread needs to explicitly use the Derby TG?
> Access denied (java.lang.RuntimePermission modifyThreadGroup) in
> IndexStatisticsDaemonImpl.schedule()
> ------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5582
> URL: https://issues.apache.org/jira/browse/DERBY-5582
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.8.2.3
> Reporter: Kathey Marsden
>
> I user reported this exception with 10.8.2.3 - (1212722) when running
> regression tests against 10.8.
> As soon as the Index Statistics Thread was initialized they got the stack
> trace below.
> There was some discussion of this issue on the dev list:
> http://old.nabble.com/Report-of-security-manager-issue-with-10.8-and-ndexStatisticsDaemonImpl.schedule-to33137398.html
> I assume the failure is in
> runningThread = new Thread(this, "index-stat-thread");
> Stack Trace:
> java.security.AccessControlException: Access denied
> (java.lang.RuntimePermission modifyThreadGroup)
> at
> java.security.AccessController.checkPermission(AccessController.java:108)
> at
> java.lang.SecurityManager.checkPermission(SecurityManager.java:544)
> at
> com.ibm.ws.security.core.SecurityManager.checkPermission(SecurityManager.java:208)
> at
> com.ibm.ws.security.core.SecurityManager.checkAccess(SecurityManager.java:407)
> at java.lang.ThreadGroup.checkAccess(ThreadGroup.java:226)
> at java.lang.Thread.initialize(Thread.java:345)
> at java.lang.Thread.<init>(Thread.java:281)
> at java.lang.Thread.<init>(Thread.java:179)
> at
> org.apache.derby.impl.services.daemon.IndexStatisticsDaemonImpl.schedule(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericStatement.prepMinion(Unknown Source)
> at org.apache.derby.impl.sql.GenericStatement.prepare(Unknown
> Source)
> at
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.<init>(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement20.<init>(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement30.<init>(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement40.<init>(Unknown Source)
> at
> org.apache.derby.jdbc.Driver40.newEmbedPreparedStatement(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
> at
> org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(Unknown Source)
> at
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
