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.
Description of problem:
When I follow a specific sequence to install/remove bind:
1) dnf install bind
2) dnf install selinux-policy-mls
3) dnf remove bind
the remove command prints out a warning:
Running transaction
Preparing : 1/1
Running scriptlet: bind-32:9.16.23-1.el9.x86_64 1/1
Erasing : bind-32:9.16.23-1.el9.x86_64 1/1
Running scriptlet: bind-32:9.16.23-1.el9.x86_64 1/1
grep: /var/lib/selinux/mls/rpmbooleans.custom: No such file or directory
Verifying : bind-32:9.16.23-1.el9.x86_64 1/1
This is likely caused by the pretty intimidating postuninstall scriptlet assuming the package was installed with the same SELinux policy package set than it is being removed with.
Note that I didn't switch the active policy to mls, I only installed the extra package.
From a cursory look, bind seems to be importing its own policy module, so maybe it would benefit from %pretrans / %posttrans to do that whenever selinux-policy-* is installed.
In any case, the grep error message probably shouldn't be there, even if its presence might indicate a bigger issue.
Version-Release number of selected component (if applicable):
bind-9.16.23-1.el9
Scriptlets in %post were required to pass upgrade from older major release, where default of named_write_master_zones used selinux boolean used to be off, but it needs to be on to succeed restarting of named. That happens in %post on upgrade.
BIND does not ship its own policy, but changes selinux booleans. Default has been changed in selinux-policy and it should not be required in most cases. It has to be ensured only on upgrade from RHEL8 selinux-policy and corresponding BIND. Should be updated first in Fedora.
I think using OrderWithRequires(post): selinux-policy should be used instead of hard dependencies if possible.
But I am using %selinux_set_booleans macro provided by selinux-policy. I am not aware of any better detection mls is active. I would expect the macro might detect itself mls is active or ready to use. I don't know how to check it otherwise. But I would like to get rid of using this macro anyway.
Comment 4RHEL Program Management
2023-07-29 07:28:06 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.