[
https://issues.apache.org/jira/browse/DERBY-6619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-6619:
--------------------------------------
Attachment: system-loader.diff
If I've understood DERBY-3745 correctly, this code is there in order to protect
against the case where the thread that starts Derby, has a context class loader
that is different from the system class loader. In such cases, if the timer
thread inherits the context class loader, the context class loader will stay in
memory until the Derby engine is shut down, even if all other references to the
class loader are gone.
If the context class loader is the same as the system class loader, on the
other hand, such a "leak" would not be a problem, since the system class loader
will stay in memory until the JVM is shut down anyway.
I'm wondering if it would be OK to take advantage of this and only attempt to
change the context class loader if it is different from the system class
loader. See the attached patch [^system-loader.diff].
With that patch, no warning is printed to derby.log when I start the server
from the command line, and there's no warning when I start the server using the
API with a security manager installed when the context class loader hasn't been
changed from the default. However, if the server is started using the API with
a non-default context class loader, I do see warnings in derby.log if a
security manager is installed. This behaviour sounds fine to me, since only the
last scenario could potentially suffer from the leak.
For the record, all regression tests ran cleanly with the patch, except an
expected failure in SecureServerTest where we check that the warning is always
printed if a security manager is installed.
> 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.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)
