db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5582) Access denied (java.lang.RuntimePermission modifyThreadGroup) in IndexStatisticsDaemonImpl.schedule()
Date Thu, 26 Jan 2012 19:01:41 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13194084#comment-13194084
] 

Kristian Waagan commented on DERBY-5582:
----------------------------------------

Ok.
Explicitly specifying the thread group to create the new thread should take care of most scenarios,
like the one reported by this user.
There's one other thing to consider. There's a group of operations / method calls that go
through check-methods in the security manager, and most of the time these check-methods simply
quietly return. Examples are (all relevant to Derby) new ThreadGroup(...), Thread.setDaemon(),
and new Thread(...). It is rare (based on the number of error reports we've seen) but possible
to write custom check-methods that would require permissions to be granted for these operations
even if they don't involve system threads or system thread groups. By wrapping these calls
in doPrivileged-blocks, we would make it easier to write such custom check-methods.
Is this something that sounds useful?

I can try to write a sample to make it easier to understand the issue. Note that this is different
from, but also similar to, the issue reported by this JIRA. The custom security manager of
the system used by the user was protecting one or more thread groups from modification, whereas
what I'm talking about here is restricting sensitive thread operations in a broader sense
(i.e. you would have to grant certain permissions to all code bases creating thread groups
and/or threads).


I think when to create the index statistics thread was discussed during the development of
the feature. The conclusion was that we didn't want another per-database thread, mostly idle,
hanging around.
                
>  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: Derby5582Runner.java, MySecurityManager.java, derby-5582_10_8_try1_diff.txt,
derby5582.policy
>
>
> 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

        

Mime
View raw message