[
https://issues.apache.org/jira/browse/DERBY-6617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14061862#comment-14061862
]
Knut Anders Hatlen commented on DERBY-6617:
-------------------------------------------
The heisenbug turned up on many platform in the latest test cycle:
http://download.java.net/javadesktop/derby/request_5593785/
I think I see what's going on. The process that's started by the test case is
an interactive ij session. This means it will hang forever waiting for input.
The test kills it by calling SpawnedProcess.complete() with a timeout of three
seconds. Since the process won't complete in three seconds, complete() goes on
to closing all the streams of the process and destroying it. Closing stdin of
the process will make ij terminate normally with exit code 0. However, if
Process.destroy() is called before ij's termination code has completed, the
process will be forcefully terminated, and its return code will be non-zero. So
there's a race between ij's self-termination code and the test's call to
Process.destroy(), and the outcome of the race determines the exit code. The
test asserts that the exit code is 0.
> Silently swallowed SecurityExceptions may disable Derby features, including
> security features.
> ----------------------------------------------------------------------------------------------
>
> Key: DERBY-6617
> URL: https://issues.apache.org/jira/browse/DERBY-6617
> Project: Derby
> Issue Type: Bug
> Components: Services
> Affects Versions: 10.11.0.0
> Reporter: Rick Hillegas
> Assignee: Dag H. Wanvik
> Attachments: derby-6617-04-aa-platformSpecificErrorText.diff,
> derby-6617-1.diff, derby-6617-2.diff, derby-6617-2.status, derby-6617-3.diff,
> derby-6617-3.status, derby-6617-junit.diff, fix-test.diff
>
>
> When the Monitor tries to read Derby properties, it silently swallows
> SecurityExceptions. This means that the properties will be silently ignored
> if Derby has not been granted sufficient privileges. This means that if you
> make a mistake crafting your security policy, then you may disable
> authentication and authorization. You may not realize this until you have
> incurred a security breach. This swallowing occurs at the following code
> locations:
> {noformat}
> org.apache.derby.impl.services.monitor.BaseMonitor readApplicationProperties
> Catch java.lang.SecurityException 1 line 1360
> org.apache.derby.impl.services.monitor.BaseMonitor runWithState Catch
> java.lang.SecurityException 0 line 280
> org.apache.derby.impl.services.monitor.FileMonitor PBgetJVMProperty Catch
> java.lang.SecurityException 1 line 183
> org.apache.derby.impl.services.monitor.FileMonitor PBinitialize Catch
> java.lang.SecurityException 1 line 120
> {noformat}
> SecurityExceptions are swallowed at other locations in the Monitor. The
> implications of these swallowings should be understood and, at a minimum,
> security problems should be fixed:
> {noformat}
> org.apache.derby.impl.services.monitor.FileMonitor PBinitialize Catch
> java.lang.SecurityException 1 line 157
> org.apache.derby.impl.services.monitor.FileMonitor createDaemonGroup Catch
> java.lang.SecurityException 1 line 89
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
