Bug 1776086

Summary:	[RHEL8]rngd.service unable to adjust write_wakeup_threshold: Permission denied
Product:	Red Hat Enterprise Linux 8	Reporter:	Frank Liang <xiliang>
Component:	rng-tools	Assignee:	Neil Horman <nhorman>
Status:	CLOSED DUPLICATE	QA Contact:	Vilém Maršík <vmarsik>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	8.2	CC:	core-kernel-mgr, leiwang, linl, ribarry, rvr, vkuznets, wshi, ymao, yuxisun
Target Milestone:	rc	Keywords:	Regression
Target Release:	8.2
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-12-02 16:14:29 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Frank Liang 2019-11-25 06:15:38 UTC

There is a regression if run rngd as unprivileged user(bz#1692435?). rngd has no permission to write to "/proc/sys/kernel/random/write_wakeup_threshold".
It always reports "unable to adjust write_wakeup_threshold: Permission denied".

[root@ip-10-116-2-80 ec2-user]# dmesg|grep -i rngd
[   11.275042] systemd[1]: rngd.service: Current command vanished from the unit file, execution of the command list won't be resumed.
[   11.297211] systemd[1]: rngd.service: Main process exited, code=killed, status=6/ABRT
[   11.306484] systemd[1]: rngd.service: Failed with result 'signal'.

[root@ip-10-116-2-52 proc]# grep 988 /etc/passwd
rngd:x:988:988:Random Number Generator Daemon:/var/lib/rngd:/sbin/nologin
[root@ip-10-116-2-80 ec2-user]# systemctl status rngd
● rngd.service - Hardware RNG Entropy Gatherer Daemon
   Loaded: loaded (/usr/lib/systemd/system/rngd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-11-25 06:03:24 UTC; 25s ago
 Main PID: 772 (rngd)
    Tasks: 3 (limit: 26213)
   Memory: 3.6M
   CGroup: /system.slice/rngd.service
           └─772 /sbin/rngd -f

Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal systemd[1]: Started Hardware RNG Entropy Gatherer Daemon.
Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal rngd[772]: Initializing available sources
Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal rngd[772]: Failed to init entropy source hwrng
Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal rngd[772]: Enabling RDSEED rng support
Nov 25 06:03:24 ip-10-116-1-193.us-west-2.compute.internal rngd[772]: Initializing entropy source rdrand
Nov 25 06:03:28 ip-10-116-2-80.us-west-2.compute.internal rngd[772]: Initializing AES buffer
Nov 25 06:03:28 ip-10-116-2-80.us-west-2.compute.internal rngd[772]: Enabling JITTER rng support
Nov 25 06:03:28 ip-10-116-2-80.us-west-2.compute.internal rngd[772]: Initializing entropy source jitter
Nov 25 06:03:28 ip-10-116-2-80.us-west-2.compute.internal rngd[772]: unable to adjust write_wakeup_threshold: Permission denied

[root@ip-10-116-2-52 proc]# ls -l /proc/sys/kernel/random/write_wakeup_threshold
-rw-r--r--. 1 root root 0 Nov 25 05:24 /proc/sys/kernel/random/write_wakeup_threshold

[root@ip-10-116-2-80 ec2-user]# rpm -qa|grep rng
rng-tools-6.8-1.el8.x86_64

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

RHEL Version:
RHEL8.2(4.18.0-151.el8.x86_64)

How reproducible:
100%

Steps to Reproduce:
1. Start a RHEL8.2 in aws.
2. check rngd.service status

Actual results:
unable to adjust write_wakeup_threshold: Permission denied

Expected results:
No such failure

Additional info:
- No such failure in RHEL8.1(rng-tools-6.6-2.el8.x86_64, run as root)

Comment 1 Neil Horman 2019-11-25 13:56:52 UTC

This isnt a regression, the service still works just fine, it just issues a warning about not being able to adjust the write wakeup threshold because we're running as a non-root user.  There is a onetime service added to RHEL which does this on rngd's behalf.  We could remove the warning, but then users who have legitimate permission issues, and no other service to do this setting for them would not be aware of the issue.  I suppose I could augment the warning to indicate that its not fatal, but I cant remove it entirely.  Is that acceptable?

Comment 2 Frank Liang 2019-11-25 14:41:12 UTC

(In reply to Neil Horman from comment #1)
> This isnt a regression, the service still works just fine, it just issues a
> warning about not being able to adjust the write wakeup threshold because
> we're running as a non-root user.  There is a onetime service added to RHEL
> which does this on rngd's behalf.  We could remove the warning, but then
> users who have legitimate permission issues, and no other service to do this
> setting for them would not be aware of the issue.  I suppose I could augment
> the warning to indicate that its not fatal, but I cant remove it entirely. 
> Is that acceptable?

Yes, I see the rngd service is in running state and it is acceptable to make the warning more clear.

Do you have any idea of dmesg output? Seems it is another problem. If yes, I can filed a separate bug for it.

# dmesg|grep -i rngd
[   11.275042] systemd[1]: rngd.service: Current command vanished from the unit file, execution of the command list won't be resumed.
[   11.297211] systemd[1]: rngd.service: Main process exited, code=killed, status=6/ABRT
[   11.306484] systemd[1]: rngd.service: Failed with result 'signal'.

Comment 3 Frank Liang 2019-11-26 08:34:00 UTC

(In reply to Xiao, Liang from comment #2)
> (In reply to Neil Horman from comment #1)
> > This isnt a regression, the service still works just fine, it just issues a
> > warning about not being able to adjust the write wakeup threshold because
> > we're running as a non-root user.  There is a onetime service added to RHEL
> > which does this on rngd's behalf.  We could remove the warning, but then
> > users who have legitimate permission issues, and no other service to do this
> > setting for them would not be aware of the issue.  I suppose I could augment
> > the warning to indicate that its not fatal, but I cant remove it entirely. 
> > Is that acceptable?
> 
> Yes, I see the rngd service is in running state and it is acceptable to make
> the warning more clear.
> 
> Do you have any idea of dmesg output? Seems it is another problem. If yes, I
> can filed a separate bug for it.
> 
> # dmesg|grep -i rngd
> [   11.275042] systemd[1]: rngd.service: Current command vanished from the
> unit file, execution of the command list won't be resumed.
> [   11.297211] systemd[1]: rngd.service: Main process exited, code=killed,
> status=6/ABRT
> [   11.306484] systemd[1]: rngd.service: Failed with result 'signal'.

Let's keep this bug for making log more clear. I filed another bug 1776710 for tracking that rngd takes longer time in boot up.

Comment 4 Neil Horman 2019-11-26 14:25:26 UTC

Why would we keep this bug open?  Whats it going to clarify if we're not going to change anything?

Comment 5 Frank Liang 2019-12-02 03:06:47 UTC

(In reply to Neil Horman from comment #4)
> Why would we keep this bug open?  Whats it going to clarify if we're not
> going to change anything?

I suspect you will do some change to highlight that the "Permission denied" error is not fatal or just a harmless warning. So I said keep this open for tracking your change.

Comment 6 Neil Horman 2019-12-02 16:14:29 UTC

I think I found a way around this.  I can add a special value to fill_watermark to indicate that no watermark should be set, and use that to avoid the warning entirely.  I'm going to fix this as part of 1776710

*** This bug has been marked as a duplicate of bug 1776710 ***