When running sa-update out of cron.daily, selinux logs these denies in the audit.log

node=localhost type=AVC msg=audit(1688552528.749:332239): avc:  denied  { write } for  pid=63266 comm="sa-update" name=".spamassassin" dev="md1" ino=116198 scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:spamc_home_t:s0 tclass=dir permissive=0
node=localhost type=AVC msg=audit(1688552530.625:332242): avc:  denied  { read } for  pid=63266 comm="sa-update" name=".spamassassin" dev="md1" ino=116198 scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:spamc_home_t:s0 tclass=dir permissive=0
node=localhost type=AVC msg=audit(1688552530.625:332243): avc:  denied  { write } for  pid=63266 comm="sa-update" name=".spamassassin" dev="md1" ino=116198 scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:spamc_home_t:s0 tclass=dir permissive=0

inode 116198 is /root/.spamassassin
# ls -lZ /root/.spamassassin
-rw-rw-r--. root root system_u:object_r:spamc_home_t:s0 user_prefs


In a previous bug (864501) user Scott said "The code that causes this is in /usr/bin/sa-update calling the function lint_check_dir() when the downloaded spam rules are checked for correctness.  A instance of Mail::SpamAssassin is created, and lint_rules() is called on it, which calls init(1) (use_user_pref=1) in turn calling get_and_create_userstate_dir(), which stats $self->{user_dir}, ".spamassassin") looking for a user pref."

This use_user_prefs is basically hard coded even though SpamAssassin::init takes use_user_prefs as an argument it does this a few lines down.

  #fix spamd reading root prefs file
  if (!defined $use_user_pref) {
    $use_user_pref = 1;
  }

Not sure if this is some sort of hack that got left in place or what but it essentially makes it so it always tries to use user prefs.

I'm don't know if I have something misconfigured or if this is an actual bug.

Either spamassassin shouldn't be forced to use user prefs when running sa-update OR read/write should be added to the policy.
My audit2allow wants me to add this:
allow spamd_update_t spamc_home_t:dir { read write };

This is what is in the current policy:
# grep 'allow spamd_update_t spamc_home_t' spamassassin.cil
(allow spamd_update_t spamc_home_t (dir (getattr open search)))
(allow spamd_update_t spamc_home_t (dir (getattr open search)))

Running the latest version 4.0 of spamassassin.