RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1679745 - pam_systemd timeouts after upgrade to systemd-219-62.el7_6.5
Summary: pam_systemd timeouts after upgrade to systemd-219-62.el7_6.5
Keywords:
Status: CLOSED DUPLICATE of bug 1687452
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.6
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-02-21 18:27 UTC by Gunnar Guðvarðarson
Modified: 2019-04-24 05:39 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-04-24 05:39:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Gunnar Guðvarðarson 2019-02-21 18:27:51 UTC
Description of problem:

After upgrading from `systemd-219-62.el7_6.3` to `systemd-219-62.el7_6.5` this issue appeared.

When running any `sudo` command from a `staff_u` selinux confined user, the sudo invocation takes 25 seconds to complete.

Downgrading resolves the issue.

Removing `-session optional pam_systemd.so` from /etc/pam.d/system-auth resolves the issue.

Setting selinux to permissive also resolves the issue.

Installing a selinux module with:

> allow staff_sudo_t systemd_logind_sessions_t:fifo_file write;

Also resolves the issue. However that particular selinux deny also appears with `systemd-219-62.el7_6.3` (without affecting sudo), which is why we do not think it solves the root cause.

Making the user `unconfined_u` resolves the issue.

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

systemd-219-62.el7_6.3 works
systemd-219-62.el7_6.5 broken

How reproducible:

Always

Steps to Reproduce:

* see below *

Actual results:

Sudo is really slow

Expected results:

Sudo is fast

Additional info:

Debugged on freenode #centos with Kosch and sfix

Steps to Reproduce (continued):

From a clean CentOS 7 minimal installation with all updates applied.

> [root@proclidev03 ~]# sudo yum install policycoreutils-python -y
> [...]
> [root@proclidev03 ~]# getenforce
> Enforcing
> [root@proclidev03 ~]# semodule -DB
> [root@proclidev03 ~]# useradd bacon
> [root@proclidev03 ~]# gpasswd -a bacon wheel
> Adding user bacon to group wheel
> [root@proclidev03 ~]# passwd bacon
> Changing password for user bacon.
> New password: 
> BAD PASSWORD: The password is shorter than 8 characters
> Retype new password: 
> passwd: all authentication tokens updated successfully.
> [root@proclidev03 ~]# 

Open another SSH session to the `bacon` user.

> [bacon@proclidev03 ~]$ date; sudo date
> Thu Feb 21 17:55:40 UTC 2019
> [sudo] password for bacon: 
> Thu Feb 21 17:55:41 UTC 2019

Go back to the `root` session.

> [root@proclidev03 ~]# semanage login -a -s 'staff_u' bacon
> [root@proclidev03 ~]# semanage login -l
> 
> Login Name           SELinux User         MLS/MCS Range        Service
> 
> __default__          unconfined_u         s0-s0:c0.c1023       *
> bacon                staff_u              s0-s0:c0.c1023       *
> root                 unconfined_u         s0-s0:c0.c1023       *
> system_u             system_u             s0-s0:c0.c1023       *
> [root@proclidev03 ~]# restorecon -RF /home/bacon

Logout from the `bacon` session and back in.

> [bacon@proclidev03 ~]$ date; sudo date
> Thu Feb 21 17:58:15 UTC 2019
> [sudo] password for bacon: 
> Thu Feb 21 17:58:42 UTC 2019

When we look at /var/log/audit/audit.log we see the following entry:

> type=AVC msg=audit(1550772716.488:303): avc:  denied  { write } for  pid=24706 comm="sudo" path="/run/systemd/sessions/5.ref" dev="tmpfs" ino=50169 scontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file permissive=0

The audit2allow utility suggests we apply the following rule:

> allow staff_sudo_t systemd_logind_sessions_t:fifo_file write;

By installing a SELinux module that allows this rule, sudo once again becomes responsive.

> [root@proclidev03 ~]# echo 'type=AVC msg=audit(1550772716.488:303): avc:  denied  { write } for  pid=24706 comm="sudo" path="/run/systemd/sessions/5.ref" dev="tmpfs" ino=50169 scontext=staff_u:staff_r:staff_sudo_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file permissive=0' | audit2allow -a -M logindtest
> ******************** IMPORTANT ***********************
> To make this policy package active, execute:
> 
> semodule -i logindtest.pp
> 
> [root@proclidev03 ~]# semodule -i logindtest.pp

Go back to the `bacon` session.
 
> [bacon@proclidev03 ~]$ date; sudo date
> Thu Feb 21 18:15:30 UTC 2019
> Thu Feb 21 18:15:30 UTC 2019

Please note that we observe the same SELinux deny with `systemd-219-62.el7_6.3` along with the exact same suggestion from `audit2allow`. However, with the older systemd version, the sudo command is not affected with this slowness as demonstrated earlier.

Comment 2 Jan Synacek 2019-02-22 09:34:37 UTC
Is this on RHEL-7.6, or CentOS? When you downgrade, which packages get downgraded? Is it just systemd, or others as well?

Comment 3 Gabríel Arthúr Pétursson 2019-02-22 12:52:47 UTC
Hi,

We tested initially on CentOS 7, but affects RHEL 7.6 too. Just spun up a fresh RHEL 7.6 installation with updates applied and we observe the same symptoms there.

We performed the downgrade with the following command:

> yum downgrade systemd systemd-libs systemd-networkd systemd-resolved systemd-sysv

The issue resolves itself immediately after a downgrade, and resurfaces after a yum update. We did not downgrade nor update any other packages.

Thanks!

P.S.

> # cat /etc/os-release
> NAME="Red Hat Enterprise Linux Server"
> VERSION="7.6 (Maipo)"
> ID="rhel"
> ID_LIKE="fedora"
> VARIANT="Server"
> VARIANT_ID="server"
> VERSION_ID="7.6"
> PRETTY_NAME="Red Hat Enterprise Linux"
> ANSI_COLOR="0;31"
> CPE_NAME="cpe:/o:redhat:enterprise_linux:7.6:GA:server"
> HOME_URL="https://www.redhat.com/"
> BUG_REPORT_URL="https://bugzilla.redhat.com/"
> 
> REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
> REDHAT_BUGZILLA_PRODUCT_VERSION=7.6
> REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
> REDHAT_SUPPORT_PRODUCT_VERSION="7.6"

Comment 4 David Tardon 2019-02-25 12:38:06 UTC
Works with systemd-219-62.el7_6.4, reproducible with systemd-219-62.el7_6.5. The CreateSession dbus call times out.

Comment 5 David Tardon 2019-02-25 13:44:53 UTC
Once more, this time without missing words: The CreateSession dbus call *in pam_sm_open_session() in pam_systemd* times out.

Comment 6 Joshua Megerman 2019-03-06 14:46:02 UTC
Can confirm that this is happening on brand new RHEL 7.6 installs.  I'm working on an upgrade to a system that has a custom SELinux policy module related to sudo and without the line 'allow <type> systemd_logind_sessions_t:fifo_file write' sudo takes a long time.

Comment 7 Gunnar Guðvarðarson 2019-04-23 18:10:29 UTC
Solved in duplicate bug https://bugzilla.redhat.com/show_bug.cgi?id=1687452

https://access.redhat.com/errata/RHBA-2019:0811

Comment 8 Jan Synacek 2019-04-24 05:39:20 UTC

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


Note You need to log in before you can comment on or make changes to this bug.