I have put a couple of bug reports into the Rocky bug reporting system. There is one about selinux checkpolicy sedismod that I hope will be addressed soon.
Is there any schedule, timeline for assigning bugs? Coming to Rocky from Fedora I see a great difference in the activity in Fedora Bugzilla vs Rocky MantisBT.
Can you provide the links to the bugs that you reported?
The other question is, is it a bug, or just something you expect to be configured that way? For example the way it’s configured now could be how Red Hat intended. If you do not wish for it to behave that way, then you would need to do your own custom selinux rules to deal with that. In which case, it’s unlikely to be implemented unless it is really a bug.
Without the links, difficult to tell. Also, most bugs as well would also need to be fixed upstream, so by Red Hat, which then filter down to Rocky. Since Rocky is based on RHEL, means we only have what RHEL has (including bugs).
Here are the links to the bug reports:
0008812: sedismod does not disassemble a selinux mod file into a te file - Rocky Linux BugTracker - selinux checkpolicy sedismod
0008713: Spammassassin wants /var/lib/razor/ but does not create it - Rocky Linux BugTracker - spamassassin missing directory.
Both are actual bugs.
sedismod is supposed to take a selinux policy mod file and disassemble it to a policy te file. I use it to modify policies that have gone out of date because of updates to the software to which they apply. Then the old policy can be removed and the updated policy installed.
Spamassassin does not create a needed directory.
Spamassassin runs with a parameter for razor-home-dir - which one would assume that if razor is not installed, then it would’t use it anyway. It’s just configured to look for this directory if razor is installed. This also happens on RHEL 9.x.
The parameter is configured here:
root@rocky9:~# cat /etc/sysconfig/spamassassin
# Options to spamd
SPAMDOPTIONS="-c -m5 -H --razor-home-dir='/var/lib/razor/' --razor-log-file='sys-syslog'"
one can do this:
# Options to spamd
SPAMDOPTIONS="-c -m5 -H"
and spamassassin still works and doesn’t look for the razor home directory. Also perl-Razor-Agent comes from EPEL and so not part of base/appstream repositories like spamassassin is. Also the /var/lib/razor directory shouldn’t be created by spamassassin anyway, since this directory should be created when razor is installed.
This would most likely need to be raised upstream since it’s the same in RHEL 9.x and since Rocky is based on RHEL it would need to be fixed higher up if it is actually a problem. The fix here would be to remove it from the spamassassin sysconfig file as shown above, but it is most likely configured that way on the event that razor is installed and it already knows where to find it - rather than manually adding it to spamassassin config later.
EDIT:
One more thing with razor, when it’s installed it should do something like this:
razor-admin -home=/etc/mail/spamassassin/.razor -register
razor-admin -home=/etc/mail/spamassassin/.razor -create
razor-admin -home=/etc/mail/spamassassin/.razor -discover
this was how I’ve used it previously on Debian-based distributions, therefore one would assume that the razor package during installation should do something like:
razor-admin -home=/var/lib/razor -register
razor-admin -home=/var/lib/razor -create
razor-admin -home=/var/lib/razor -discover
which it’s most likely not doing.
Spamassassin is configured to use razor, because razor is installed.
The directory /var/lib/razor/ and its contents are labeled system_u:object_r:spamd_var_lib_t:s0 by selinux. I made the assumption since the configuration of spamassassin specifies razor and the selinux context assigns the directory to spamd, then it would be spamassassin’s responsibility to create the directory. Since spamassassin is in the @appstream, that is why I reported it to Rocky rather than EPEL.
Hmm well not necessarily. Since spamassassin can be installed without razor, it would be expected that if razor is installed, then razor should create it’s own directory. Selinux context is something else entirely - and most likely named spamd because razor is a spamssassin module.
The question here is, should spamassassin be configured to search the razor directory by default when razor is not installed? The daemon works irrespective anyway. In Debian it was enough to configure local.cf and v310.pre to enable the razor module and use it. And using the razor-admin commands were the ones that configured the directory and where all it’s relevant files should exist. I believe the perl-Razor-Agent package should be doing this which it isn’t. But I expect that is something for the Dev’s to decide.
This also happens in RHEL 9.x so would need to be fixed in RHEL9 if it actually is a bug or not. Most likely RHEL/EPEL devs would be able to explain why it is that way.
As to when bugs get fixed/assigned etc, I’ve had bugs open for months before anyone actually did anything with them, and you would think when paying a company for support/subscription that it would be done quicker. Sadly not.
The question for spamassassin is going to be a question for Red Hat. You can open a bug at issues.redhat.com against RHEL 9/CentOS Stream 9 and detail the same information, but you’ll likely be given this information:
%global razor_deps 0
Only non-rhel builds will have razor built
%if ! 0%{?rhel}
%global patricia_deps 1
%global razor_deps 1
%endif
. . .
%if %{razor_deps}
Requires: perl-Razor-Agent
BuildRequires: perl-Razor-Agent
%endif
. . .
%if %{razor_deps}
mkdir -m 0700 -p $RPM_BUILD_ROOT%{_sharedstatedir}/razor/
%endif
. . .
%if %{razor_deps}
%dir %{_sharedstatedir}/razor
%endif
. . .
%if %{razor_deps}
rm -f %{_sharedstatedir}/razor/*
%endif
As razor is provided by EPEL, then additional configuration is required (as you’ve figured out). If you believe this should be handled by the spamassassin package itself, it’ll be a question for the mtaintainers at Red Hat.
One more test I did, if I create the directory like you did without the razor module installed, then nothing appears in /var/lib/razor directory.
root@rocky9:~# systemctl start spamassassin
root@rocky9:~# ps aux | grep -i razor
root 11125 65.7 2.6 119736 107168 ? Ss 18:25 0:02 /usr/bin/perl -T -w /usr/bin/spamd -c -m5 -H --razor-home-dir=/var/lib/razor/ --razor-log-file=sys-syslog
root 11132 0.0 0.0 6404 2176 pts/0 S+ 18:25 0:00 grep --color=auto -i razor
root@rocky9:~# systemctl stop spamassassin
root@rocky9:~# mkdir /var/lib/razor
root@rocky9:~# restorecon -Rv /var/lib/razor/
Relabeled /var/lib/razor from unconfined_u:object_r:var_lib_t:s0 to unconfined_u:object_r:spamd_var_lib_t:s0
root@rocky9:~# systemctl start spamassassin
root@rocky9:~# cd /var/lib/razor/
root@rocky9:/var/lib/razor# ls -lha
total 4.0K
drwxr-xr-x. 2 root root 6 Jan 14 18:25 .
drwxr-xr-x. 31 root root 4.0K Jan 14 18:25 ..
Therefore, the directory should be created and populated only when razor plugin is installed, and not by spamassassin. At least that’s the way I see it 
Thanks for investigating.
I’m going to leave the bug where it is and let the devs decide.
As much as I disliked the aggressive 6 month version schedule of Fedora, the bug fixes were just as aggressive as the update schedule which was nice.