[ 
https://issues.apache.org/jira/browse/RANGER-2700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17016579#comment-17016579
 ] 

Pradeep Agrawal commented on RANGER-2700:
-----------------------------------------

[~liujiayi771] : Can you add the testing done for this patch in RR. Please add 
the testing for upgrade case as well.

> creating service sometimes fails because SecureRandom.getInstanceStrong() is 
> often blocked
> ------------------------------------------------------------------------------------------
>
>                 Key: RANGER-2700
>                 URL: https://issues.apache.org/jira/browse/RANGER-2700
>             Project: Ranger
>          Issue Type: Improvement
>          Components: admin
>    Affects Versions: ranger-2.0
>            Reporter: Jiayi Liu
>            Priority: Major
>         Attachments: 0001-RANGER-2700.patch
>
>
> I try to install ranger-2.0.0 on my cluster, however, I try to create a new 
> service in Ranger WebUI, when I click the Add button, I keep stuck in the 
> Please waiting state for a long time, and finally get an error that 
> createService failed.
>  I try to debug through the source code, and found that it stuck on 
> generateBase64EncodedIV() in PasswordUtils.java. It uses 
> SecureRandom.getInstanceStrong() to get the random string. We can find a lot 
> of information showing that this function often blocks and is very slow. 
> SecureRandom.getInstanceStrong() uses /dev/random, and /dev/random blocks the 
> thread if there isn't enough randomness available, but /dev/urandom will 
> never block. 
> SecureRandom.getInstanceStrong() is equivalent to 
> SecureRandom.getInstance("NativePRNGBlocking"), so we can use /dev/urandom by 
> replacing SecureRandom.getInstanceStrong().nextBytes(iv) with 
> SecureRandom.getInstance("NativePRNGNonBlocking").nextBytes(iv) which will 
> not be blocked, or we can use new SecureRandom().nextBytes(iv). /dev/random 
> and /dev/urandom use the same pool of randomness under the hood, and they are 
> equally secure. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to