[
https://issues.apache.org/jira/browse/DERBY-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14109355#comment-14109355
]
ASF subversion and git services commented on DERBY-6619:
--------------------------------------------------------
Commit 1620385 from [~dagw] in branch 'code/trunk'
[ https://svn.apache.org/r1620385 ]
DERBY-6619 After silently swallowing SecurityExceptions, Derby can leak class
loaders
Patch derby-6619-2-refinement which implements the following
refinements to the test to avoid changing the context class loader in
SingletonTimerFactory (suggested by Knut):
The orginal test tested against the system class loader. This new patch will:
1) Check if the context class loader is the same as the loader of the
SingletonTimerFactory class (that is, the class loader from which
Derby classes are loaded). Even if this isn't the same as the system
class loader, it would be safe to skip the workaround for DERBY-3745,
since the class loader for the Derby classes would not be eligible for
garbage collection until the engine is shut down anyway. This would
prevent some more false positives from being reported in
derby.log. I'd assume this is a kind of false positive that could
easily occur in an application server environment where the Derby
classes are not found on the system class loader.
2) Check against Thread.class.getClassLoader() instead of
ClassLoader.getSystemClassLoader(). Normally, those two checks would
be identical. If however the setup is such that they aren't identical,
we'd still know that the class loader actually used for system classes
such as the Thread class would have to stay in memory for as long as
the timer thread is alive, regardless of the context class loader of
the thread, so the workaround for DERBY-3745 can be skipped if it's
the same as the context class loader. The check will be a bit more
specific this way.
> After silently swallowing SecurityExceptions, Derby can leak class loaders
> --------------------------------------------------------------------------
>
> Key: DERBY-6619
> URL: https://issues.apache.org/jira/browse/DERBY-6619
> Project: Derby
> Issue Type: Bug
> Components: Services
> Reporter: Rick Hillegas
> Assignee: Dag H. Wanvik
> Fix For: 10.11.1.2, 10.12.0.0
>
> Attachments: derby-6619-2-refinement.diff, derby-6619-2.diff,
> derby-6619-2b.diff, derby-6619.diff, derby-6619.status, derby-6619b.diff,
> derby-6619c.diff, derby.log, system-loader.diff
>
>
> As part of the fix for DERBY-3745, Derby silently swallows security
> exceptions and leaks class loaders. This can give rise to denial-of-service
> attacks. At a minimum, Derby should report the swallowed exceptions so that
> the security policy can be corrected and the application can be hardened
> against this attack. The swallowing occurs at these locations:
> {noformat}
> org.apache.derby.impl.services.timer.SingletonTimerFactory run Catch
> java.lang.SecurityException 0 line 175
> org.apache.derby.impl.services.timer.SingletonTimerFactory run Catch
> java.lang.SecurityException 1 line 158
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
