On Tue, 2024-09-10 at 13:45 +0100, Barry wrote:

...

On 10 Sep 2024, at 11:31, Patrick O'Callaghan pocallaghan@gmail.com wrote:

I have a cron line that attempts to restart httpd every morning, but it's failing with an AVC error:

Sep 10 08:00:00 Bree CROND[723189]: (root) CMD ((echo "$(date): Apache: calling restart") >> /var/log/httpd/my-log && /usr/sbin/apachectl restart) Sep 10 08:00:00 Bree systemd[1]: selinux: avc: denied { start } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/httpd.service" cmdline="" function="bus_unit_method_start_generic" scontext=system_u:system_r:httpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:httpd_unit_file_t:s0 tclass=service permissive=0

My SElinux-fu is not up to this. Any thoughts?

Cannot answer for the selinux, but wonder if systemctl restart httpd would work?

apachectl is just a Shell script that calls on systemctl after massaging some arguments.

Also curious why you need the restart, I have always found httpd to be very reliable.

I suspend my system overnight and resume automatically in the morning, but have found that httpd often fails to resume. Sometimes it does, sometimes it doesn't. I reported this to BZ about a year ago, with a recent update on the report. The restart cron line is an attempt at a workaround.

Note that suspending/resuming the system manually always works, so it's a mystery.

poc

On Tue, 2024-09-10 at 11:55 -0500, Thomas Cameron wrote:

On 9/10/24 5:30 AM, Patrick O'Callaghan wrote:

...

I have a cron line that attempts to restart httpd every morning, but it's failing with an AVC error:

Sep 10 08:00:00 Bree CROND[723189]: (root) CMD ((echo "$(date): Apache: calling restart") >> /var/log/httpd/my-log && /usr/sbin/apachectl restart) Sep 10 08:00:00 Bree systemd[1]: selinux: avc: denied { start } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/httpd.service" cmdline="" function="bus_unit_method_start_generic" scontext=system_u:system_r:httpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:httpd_unit_file_t:s0 tclass=service permissive=0

My SElinux-fu is not up to this. Any thoughts?

Patrick -

I did a presentation at Red Hat Summit on SELinux a few years ago. If you're willing to spend about 45 minutes, you can learn some tools to figure out why it's throwing that error and how to fix or report it.

https://www.youtube.com/watch?v=_WOKRaM-HI4

Thanks. I had seen that video some time ago but took another look. A couple of points:

There are no setroubleshoot lines in the journal, just the line I quoted. setroubleshootd is installed and running. auditd is installed but not running:

$ systemctl status auditd ○ auditd.service - Security Audit Logging Service Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled; preset: enabled) Drop-In: /usr/lib/systemd/system/service.d └─10-timeout-abort.conf Active: inactive (dead) Condition: start condition unmet at Wed 2024-09-11 11:51:08 BST; 10min ago └─ ConditionKernelCommandLine=!audit=0 was not met Docs: man:auditd(8) https://github.com/linux-audit/audit-documentation

Sep 11 11:51:08 Bree systemd[1]: auditd.service - Security Audit Logging Service was skipped because of an unmet condition check (ConditionKernelCommandLine=!audit=0).

Does this really mean I have to modify the boot line to get auditd to run? The video doesn't mention this as far as I know.

*HOWEVER*

Turns out I don't need any of this. If I substitute my original crontab line for one that simply calls a Shell script which in turn calls apachectl, then it all works with no AVC.

How does this make sense? It seems highly counterintuitive.

poc

On Thu, 2024-09-12 at 12:14 +0930, Tim via users wrote:

On Wed, 2024-09-11 at 12:19 +0100, Patrick O'Callaghan wrote:

...

Turns out I don't need any of this. If I substitute my original crontab line for one that simply calls a Shell script which in turn calls apachectl, then it all works with no AVC.

ENVironment differences? The crontab versus your shell's? Try dumping all the ENV variables to a text file, via crontab entry.

The shell script is called directly from the crontab line, so presumably the ENV variables are the same. In any case, this the environment passed on:

SHELL=/bin/sh PWD=/root LOGNAME=root HOME=/root LANG=en_GB.UTF-8 USER=root SHLVL=1 PATH=/usr/bin:/bin:/usr/sbin:/sbin _=/usr/bin/printenv

There's nothing there that should affect SElinux.

poc

On 16 Sep 2024, at 10:48, Patrick O'Callaghan pocallaghan@gmail.com wrote:

I suspect the real problem is that the cron line is running as root, but Apache wants to run as the apache user. I'll try using 'crontab -u apache ...' to see if that makes any difference.

You said the the apachectl just rund a systemctl command. That means it is the permission to run systemctl that should be the important factor. Systemctl will run the restart as the right user.

So root will be correct, I assume.

Barry

On Mon, 2024-09-16 at 17:40 +0100, Barry wrote:

...

On 16 Sep 2024, at 10:48, Patrick O'Callaghan pocallaghan@gmail.com wrote:

I suspect the real problem is that the cron line is running as root, but Apache wants to run as the apache user. I'll try using 'crontab -u apache ...' to see if that makes any difference.

You said the the apachectl just rund a systemctl command. That means it is the permission to run systemctl that should be the important factor. Systemctl will run the restart as the right user.

So root will be correct, I assume.

That's probably correct. My change didn't seem to have any effect.

poc