[
https://issues.apache.org/jira/browse/DERBY-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13190514#comment-13190514
]
Kristian Waagan commented on DERBY-5582:
----------------------------------------
KM> 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?
It's a bit hard to say which preconditions must be met before the exception is
actually thrown. From SecurityManager.checkAccess(ThreadGroup g):
"""
If the thread group argument is the system thread group ( has a null parent)
then this method calls checkPermission with the
RuntimePermission("modifyThreadGroup") permission. If the thread group argument
is not the system thread group, this method just returns silently.
"""
Note that the documentation separates only between the system thread group and
other thread groups. In my mind the thread pool referred to above would have to
be part of the system thread group for the exception to be raised, unless there
are custom security measures in place.
Which JVM was the issue seen on?
KM> So maybe the call to new up the statistics thread needs to explicitly use
the Derby TG?
Yes, I think that's the right thing to do in any case. That could also make it
easier for someone wanting to implement a stricter security manager (i.e to
allow only some components in a stack to create new threads).
> 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
> Attachments: derby-5582_10_8_try1_diff.txt
>
>
> 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
