Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionGunnar 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.
Is this on RHEL-7.6, or CentOS? When you downgrade, which packages get downgraded? Is it just systemd, or others as well?
Comment 3Gabrí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"
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 7Gunnar Guðvarðarson
2019-04-23 18:10:29 UTC