Report scheduling broken on Rocky Linux 10.1: crontab problem (SELinux related)

[ppanula]

Describe the bug
I installed Thruk 3.26 using AlmaLinux 10 RPM and when trying to save Report there is crontab problem.
I am getting Internal server error and thruk.log has this error:
cron_pre_edit_cmd (/usr/bin/crontab -l > /var/cache/thruk/thruk_cron.tmp 2>>/tmp/Gocfg52Bje) exited with value 1:
You (apache) are not allowed to access to (crontab) because of pam configuration.

SELinux is enforcing, and thats the way i want it to be.

Thruk Version
3.26-46.11

To Reproduce
Steps to reproduce the behavior:

1. Open Thruk web gui
2. Click on Reports - Reporting
3. Pick one report and Save it
4. you got Internal server error

Additional context
I think this problem should be at least documented that on RHEL10 systems with SELinux enforced you are needed to do some workaround that you can get Report scheduling to work.

This next part is from AI that also helped to create wrapper script (Claude Opus 4.6):
Two security mechanisms combine to cause this failure:

1. SELinux httpd_t is a No New Privileges (NNP) domain

The SELinux policy marks Apache's domain as NNP via init_nnp_daemon_domain(httpd_t) in apache.te. This causes the kernel to silently suppress the setuid bit
on any binary exec'd from httpd_t. So when Thruk's FastCGI process (running as apache, uid=48, in httpd_t) execs /usr/bin/crontab:

• The setuid-root bit is ignored — crontab runs as uid=48 instead of root
• No AVC denial is logged (dontaudit rules suppress it)
• No domain transition to crontab_t occurs (no such rule in apache.te)

2. RHEL 10 cronie PAM stack denies system users

Without root, crontab falls through to PAM (/etc/pam.d/crontab). RHEL 10's cronie includes pam_access.so in this stack. Since apache is a system service
account with no login session, PAM rejects it.

Note: editing /etc/pam.d/crond has no effect — the relevant PAM stack is /etc/pam.d/crontab (used by the crontab(1) binary), which is different from
/etc/pam.d/crond (used by the crond daemon). This adds to the confusion.

sudo as a fallback also fails — httpd_t has dontaudit httpd_t self:netlink_audit_socket create_socket_perms, so sudo can't open the audit system.

Workaround (from Claude 4.6)

A setuid-root C helper binary that directly reads/writes /var/spool/cron/apache, combined with a custom SELinux policy module:

// /usr/local/bin/thruk_cron_helper
// setuid root, owned root:apache, mode 4750
// reads or writes /var/spool/cron/apache directly

SELinux policy (thruk_cron.te):

module thruk_cron 1.0;
require {
    type httpd_t; type user_cron_spool_t; type bin_t;
    class file { read write create open getattr setattr execute execute_no_trans };
    class dir { getattr search };
}
allow httpd_t bin_t:file { execute execute_no_trans };
allow httpd_t user_cron_spool_t:dir { getattr search };
allow httpd_t user_cron_spool_t:file { read write create open getattr setattr };

thruk_local.conf:

cron_pre_edit_cmd  = /usr/local/bin/thruk_cron_helper read > /var/cache/thruk/thruk_cron.tmp
cron_post_edit_cmd = /usr/local/bin/thruk_cron_helper write < /var/cache/thruk/thruk_cron.tmp && rm -f /var/cache/thruk/thruk_cron.tmp

[ppanula]

if needed/wanted i can put source code of thruk_cron_helper.c either here or make a new PR.