Bug 1319827

Summary: password-reset takes a long time
Product: [oVirt] ovirt-engine-extension-aaa-jdbc Reporter: Yedidyah Bar David <didi>
Component: GeneralAssignee: Martin Perina <mperina>
Status: CLOSED WONTFIX QA Contact: Ondra Machacek <omachace>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 1.0.4CC: bugs
Target Milestone: ---Flags: rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-03-22 09:27:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
setup-cleanup-logs.tar.gz none

Description Yedidyah Bar David 2016-03-21 15:38:51 UTC 
Description of problem:

During engine-setup, ovirt-aaa-jdbc-tool is called to set admin password.

Today I ran several times engine-setup and then engine-cleanup (while debugging an unrelated issue). In the first run, it took 1 second. In consecutive ones, it took much longer - 3:20 minutes on second, 3:57 on third, 6:15 on fourth, 1:45 on fifth. Then after engine-cleanup, stopped postgresql, renamed its data dir, and ran setup again - the tool took 1:31 minutes.

Version-Release number of selected component (if applicable):

Current master snapshot

How reproducible:

Not sure

Steps to Reproduce:
1. engine-setup
2. engine-cleanup
3. engine-setup

Actual results:

Second run takes considerably longer

Expected results:

Should take more-or-less the same time

Additional info:

Tried running everything under strace, but my /tmp reached 100% in the middle so it failed. Can try again with a larger one, or filter specific syscalls, or whatever.
Comment 1 Yedidyah Bar David 2016-03-21 15:41:24 UTC 
Created attachment 1138640 [details]
setup-cleanup-logs.tar.gz
Comment 2 Yedidyah Bar David 2016-03-22 07:37:16 UTC 
Ran again with strace and found the reason: it's waiting for /dev/random.

Workaround: Added to the script:

-Djava.security.egd=file:/dev/./urandom

See also:

http://stackoverflow.com/questions/137212/how-to-solve-performance-problem-with-java-securerandom
Comment 3 Yedidyah Bar David 2016-03-22 07:57:36 UTC 
Verified another workaround following Sandro's suggestion - use haveged.

Since this one is reasonable IMO, might close wontfix. Still not sure why we need there much random data, leaving for assignee to decide.
Comment 4 Martin Perina 2016-03-22 09:27:08 UTC 
We are encrypting password during password-reset command, so we definitely want to use secure random number generator and replacing /dev/random with /dev/urandom is not an option.

Also I have never noticed this slowness on real machine. The issue can be seen only when running the tool inside the VM and in this case you could increase entropy of the VM by using virtio-rng or haveged.

So I'm closing this as WONTFIX.
Comment 5 Yedidyah Bar David 2016-03-22 10:08:39 UTC 
AFAIU we are not "encrypting" them but hashing them, and the only thing we need a random number for is the salt. Not sure why using urandom is not an option. Might be missing something, NVM. Using the host rng or some alternative such as haveged is also good enough, considering that many people already have to do that for other reasons.
Comment 6 Martin Sivák 2018-03-15 11:40:28 UTC 
Just for the record, /dev/urandom is totally acceptable and you do not need to use /dev/random unless you are a security researcher.

Additional sources of information why we should prefer /dev/urandom:

https://www.2uo.de/myths-about-urandom/
https://pthree.org/2014/07/21/the-linux-random-number-generator/