Bug 1969488

Summary:	Errors at early start of polkit are thrown to /dev/null, while they could be useful for troubleshooting
Product:	Red Hat Enterprise Linux 7	Reporter:	Renaud Métrich <rmetrich>
Component:	polkit	Assignee:	Polkit Maintainers <polkit-devel>
Status:	CLOSED NOTABUG	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.9	CC:	fkrska, jrybar, qguo
Target Milestone:	rc
Target Release:	---
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:	2021-08-31 14:59:05 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 Renaud Métrich 2021-06-08 14:07:27 UTC

Description of problem:

When the permissions on / is 700 instead of default 555, polkit and other daemons fail to start but there is nothing special printed on the console.

In fact there is a message from polkit pointing to the issue:
~~~
1378  16:01:12.604639 write(2</dev/null<char 1:3>>, "Error switcing to user polkitd: Error changing to home directory /: Permission denied\n", 86) = 86 <0.000008>
~~~

But it's thrown to /dev/null.

Please make sure such errors make it to the journal.

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

polkit-0.112-26.el7.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Change permissions on /

  # chmod 700 /

2. Restart polkit

  # systemctl restart polkit


Actual results:

polkit fails to start with no useful error message

Expected results:

Error above (with fix for typo "switcing" please :)) seen in the journal.

Comment 2 Jan Rybar 2021-06-08 14:34:16 UTC

Hello, 
polkit is written in Glib2.

I have found this error message in code:
./src/polkitbackend/polkitd.c:206:      g_printerr ("Error switcing to user %s: %s\n",

Error and debug messages in Glib-powered applications are to be brought up differently, since Glib takes over the message handling.
https://developer.gnome.org/glib/unstable/glib-Warnings-and-Assertions.html#glib-Warnings-and-Assertions.description

To see error messages generated by polkit, a Glib global variable should be set before running polkitd (i.e. in polkit's unit file):
Exec=/bin/sh -c 'G_MESSAGES_DEBUG=all /usr/lib/polkit-1/polkitd

Reminder: RHEL7.9 has stepped into Maintenance Support 2, only important and critical RHSAs and Urgent RHBAs may be released. Please state the level of urgency of this issue.

Comment 4 Renaud Métrich 2021-06-21 06:00:48 UTC

Hi Jan,

the justification behind fixing this on RHEL7 is troubleshooting is hard and requires senior backline resources, whereas if the error messages got through to syslog, the troubleshooting would be very easy.

Renaud.

Comment 6 Jan Rybar 2021-06-23 11:04:08 UTC

Hello,

the solution is simple.
polkit's unit file:
-------------
$cat /usr/lib/systemd/system/polkit.service
[Unit]
Description=Authorization Manager
Documentation=man:polkit(8)

[Service]
Type=dbus
BusName=org.freedesktop.PolicyKit1
ExecStart=/usr/lib/polkit-1/polkitd --no-debug
-----------------

1) remove '--no-debug' option from /usr/lib/systemd/system/polkit.service
2) systemctl daemon-reload
3) systemctl restart polkit

The '--no-debug' option is responsible for redirecting STDIN, STDOUT and STDERR to /dev/null.

I agree that the listing and description of 'polkitd' options are missing from manpage and this can be fixed in upstream and eligible RHEL streams, but I don't believe such manpage fix is a matter of z-stream on RHEL-7 with Maintenance Support 2 Phase.

Comment 7 Renaud Métrich 2021-07-20 11:18:10 UTC

Hello,
Sorry I completely missed your comment.

I could test that without --no-debug polkit indeed prints enough messages to troubleshoot this issue.
I think that even though RHEL7 is in Maintenance Support 2 Phase this fix should be implemented in default polkit unit because:
- it affects customers regularly when they apply their "security recommendations" on Production systems through automation
- it's hard to troubleshoot by frontlines
- it brings no risk at all since it doesn't affect polkit's behaviour at all

@fkrska What do you think?