[ 
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]

Reply via email to