[
https://issues.apache.org/jira/browse/SOLR-8099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034117#comment-15034117
]
Yonik Seeley commented on SOLR-8099:
------------------------------------
They are useful for manual testing. I've often used sleep for testing timeout
situations.
I used the threadid s long time ago to verify that thread pools were behaving
as expected so we wouldn't use more thread locals than expected (this dates
back to when Lucene used more thread-locals).
Whether sleep should be considered a security issue? shrug.
What if it was modified to respect any timeAllowed parameter? w/o a
timeAllowed, there are dozens of ways I could construct requests that would
take a *long* time and suck up a lot more resources than sleep does.
> Remove sleep() function / ValueSourceParser
> -------------------------------------------
>
> Key: SOLR-8099
> URL: https://issues.apache.org/jira/browse/SOLR-8099
> Project: Solr
> Issue Type: Improvement
> Reporter: Ishan Chattopadhyaya
> Labels: security
> Fix For: 5.4
>
> Attachments: SOLR-8099.patch, SOLR-8099.patch
>
>
> As per Doug Turnbull, the sleep() represents a security risk.
> {noformat}
> I noticed a while back that "sleep" is a function query. Which I
> believe means I can make the current query thread sleep for as long as I
> like.
> I'm guessing an attacker could use this to starve Solr of threads, running
> a denial of service attack by running multiple queries with sleeps in them.
> Is this a concern? I realize there may be test purposes to sleep a function
> query, but I'm trying to think if there's really practical purpose to
> having sleep here.
> Best,
> -Doug
> {noformat}
> This issue is to remove it, since it is neither documented publicly, nor used
> internally very much, apart from one test suite.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]