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.
.RPM no longer hangs during a transaction involving the `fapolicyd` service restart
Previously, if you tried to update a package that caused the `fapolicyd` service to be restarted, for example, `systemd`, the RPM transaction stopped responding because the `fapolicyd` plug-in failed to communicate with the `fapolicyd` daemon.
With this update, the `fapolicyd` plug-in now correctly communicates with the `fapolicyd` daemon. As a result, RPM no longer hangs during a transaction which involves the `fapolicyd` service restart.
Created attachment 1899280[details]
test pachage (source rpm)
Description of problem:
Upgrading fapolicyd along with other packages (e.g. system) leave yum in a
hung state, writing to a fifo on which no other process reads.
Version-Release number of selected component (if applicable):
- RHEL 8.4.0 EUS
- fapolicyd-1.0.2-6.el8_4.1
- rpm-plugin-fapolicyd-4.14.3-14.el8_4.2
How reproducible:
Always
Steps to Reproduce:
1. Install of RHEL 8.4 (server with GUI). Register the system and attach the
required entitlement.
2. Lock the release version
subscription-manager release --set=8.4
2. Enable fapolicyd
# systemctl enable --now fapolicyd
3. Update the packages but leave systemd one step behind (for step 5)
# yum upgrade -y -x fapolicyd\* -x systemd\*
# yum upgrade -y systemd-239-45.el8_4.10
# yum upgrade -y fapolicyd-1.0.2-6.el8_4.1
# systemctl reboot
4. Download the attached test rpms. These are scratch builds of fapolicyd with
this change to force an upgrade:
diff --git a/fapolicyd.spec b/fapolicyd.spec
index e7d2c5c..03334a0 100644
--- a/fapolicyd.spec
+++ b/fapolicyd.spec
@@ -6,7 +6,7 @@
Summary: Application Whitelisting Daemon
Name: fapolicyd
Version: 1.0.2
-Release: 6%{?dist}.2_case03267178
+Release: 6%{?dist}.1
License: GPLv3+
URL: http://people.redhat.com/sgrubb/fapolicyd
Source0: https://people.redhat.com/sgrubb/fapolicyd/%{name}-%{version}.tar.gz
@@ -57,13 +57,6 @@ to decide file access rights. Applications that are known via a reputation
source are allowed access while unknown applications are not. The daemon
makes use of the kernel's fanotify interface to determine file access rights.
-This RPM has been provided by Red Hat for testing purposes only and is
-NOT supported for any other use. This RPM may contain changes that are
-necessary for debugging but that are not appropriate for other uses,
-or that are not compatible with third-party hardware or software. This
-RPM should NOT be deployed for purposes other than testing and
-debugging.
-
%package selinux
Summary: Fapolicyd selinux
Group: Applications/System
5. Upgrade systemd and fapolicyd in a single yum execution
# yum upgrade systemd-239-45.el8_4.11 \
./fapolicyd-1.0.2-6.el8_4.2_case03267178.x86_64.rpm \
./fapolicyd-selinux-1.0.2-6.el8_4.2_case03267178.noarch.rpm
Actual results:
Yum gets hung.
Expected results:
Successful upgrade.
Additional info:
Yum gets hung writing on the fifo used by the fapolicyd rpm plugin to communicate with fapolicyd, as
can be seen using strace:
# pid=$(pidof -x yum)
# strace -fttTvyy -s 4096 -p $pid
strace: Process 6074 attached
18:01:56.359949 write(24</run/fapolicyd/fapolicyd.fifo (deleted)>, "/usr/lib/systemd/system/remote-cryptsetup.target 549 86d9439857b2d5e306805a4a9d83e35cf9cde9e31c5305557c321c3254cc8909\n", 118
# lsof -p $pid | fgrep /run/fapolicyd/fapolicyd.fifo
yum 6074 root 24u FIFO 0,24 0t0 25332 /run/fapolicyd/fapolicyd.fifo (deleted)
The FIFO is deleted because fapolicyd has been restarted. The new fapolicyd daemon uses a different
fifo:
# ls -l /run/fapolicyd/fapolicyd.fifo
prw-rw----. 1 root fapolicyd 0 Jul 25 17:59 /run/fapolicyd/fapolicyd.fifo
# lsof -p $(pidof fapolicyd) | fgrep /run/fapolicyd/fapolicyd.fifo
fapolicyd 6120 fapolicyd 3u FIFO 0,24 0t0 46280 /run/fapolicyd/fapolicyd.fifo
So the yum process becomes blocked, writing on a FIFO on which no other process reads.
This problem should have been fixed in Bug 1896875 but is still present.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (rpm bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:3021