[jira] [Resolved] (DERBY-5571) IndexStatisticsDaemonImpl.schedule should wrap Thread.setDaemon() in a privilege block

["Myrna van Lunteren (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Myrna van Lunteren resolved DERBY-5571.
---------------------------------------

    Resolution: Won't Fix

I'm marking this as won't fix.
Instead of wrapping in a privileged block, this code has been modified to use getDaemonThread, see DERBY-5582.

> IndexStatisticsDaemonImpl.schedule  should wrap Thread.setDaemon() in a privilege block
> ---------------------------------------------------------------------------------------
>
>                 Key: DERBY-5571
>                 URL: https://issues.apache.org/jira/browse/DERBY-5571
>             Project: Derby
>          Issue Type: Bug
>          Components: Services
>    Affects Versions: 10.8.2.2
>            Reporter: Kathey Marsden
>              Labels: derby_triage10_10
>
> IndexStatisticsDaemonImple.schedule() has the following code. setDaemon can throw a SecurityException so should be wrapped. It says: SecurityException - if the current thread cannot modify this thread.
> Does this mean that our documentation should require modifyThreadGroup privs too?
> Currently it is in our test policy but not the documentation:
> // These permissions are needed by AssertFailure to dump the thread stack
>   // traces upon failure.
>   //permission java.lang.RuntimePermission "getStackTrace";
>   permission java.lang.RuntimePermission "modifyThreadGroup";
>                // If we're idle, fire off the worker thread.
>                 if (runningThread == null) {
>                     runningThread = new Thread(this, "index-stat-thread");
>                     // Make the thread a daemon thread, we don't want it to stop
>                     // the JVM from exiting. This is a precaution.
>                     runningThread.setDaemon(true);
> Marking as a regression as a security violation could make existing statements fail.
>                     



--
This message was sent by Atlassian JIRA
(v6.2#6252)