[
https://issues.apache.org/jira/browse/DERBY-6107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13944982#comment-13944982
]
Rick Hillegas commented on DERBY-6107:
--------------------------------------
Hi Knut,
Thanks for thinking so deeply about this issue and for running those
experiments. I don't think I understand the problem well enough to give any
advice yet. I have a couple questions:
1) How would this problem occur in production? Would it only surface if you are
accessing a database in a jar file on the classpath and you have enabled login
timeouts and then later on you switch to using NATIVE authentication after
having run without it for a while?
2) I don't understand the implications of granting getClassLoader and
setContextClassLoader permissions, but my sense is that those are very serious
permissions. Note that Derby calls getClassLoader() in several places but, so
far, the context has been sufficient to not trip a security exception.
3) Also, I can't find where we list those permissons as optional permissions.
Can you point me at that advice?
4) I think that threads are fairly lightweight. But memory could be exhausted
by a sufficiently large number of even very lightweight objects. Setting the
keep alive timeout to 0 may create a new opportunity for a DDoS attack. But
maybe that's red herring because the same attack might exhaust some other
resource even if the keep alive timeout weren't set to 0.
Thanks,
-Rick
> Investigate why setting a login timeout causes
> NativeAuthenticationServiceTest to fail when run in a suite
> ----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-6107
> URL: https://issues.apache.org/jira/browse/DERBY-6107
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.10.1.1
> Reporter: Rick Hillegas
> Assignee: Knut Anders Hatlen
>
> See DERBY-6094 for the details of this problem.
--
This message was sent by Atlassian JIRA
(v6.2#6252)