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).
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 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.
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:
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:
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:
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.
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