After upgrade of httpd rpm for security fix, to below version, the CGI script which was trying to read a file is not working, which was working with previous version httpd-2.4.57-2.el9 to below RPM
below error is seen in the httpd error log and modsec_auditlog
==> error_log <==
[Sat Sep 21 03:30:35.569846 2024] [cgid:error] [pid 2013978:tid 2013999] [client 10.223.74.170:48670] [Sat Sep 21 03:30:35 2024] getStartupStatus.cgi: Error opening file: No such file or directory at /var/www/maintenance/html/getStartupStatus.cgi line 28.: /var/www/maintenance/html/getStartupStatus.cgi
I have checked the access of the file it has below access, even if changed to 777 getting same error
-rw-r–r-- 1 jboss jboss 1395 Sep 18 18:42 /var/tmp/systemStartupInJSON.log
So the line 28 in your script points somehow to /var/tmp/systemStartupInJSON.log?
You can check if the user jboss can also ‘enter’ the /var/tmp (x set on the directory).
Update on the root cause of the issue.
after several checks and retries, found that the latest RPM PrivateTmp=true for httpd service in service file : /usr/lib/systemd/system/httpd.service
after making PrivateTmp=false and restarting the httpd service the cgi was able to access the file under the /var/tmp directory.
If you want to prevent the next update from overriding your custom configuration, create a file named /usr/lib/systemd/system/httpd.service.d/override.conf and place this:
Can you elaborate on this?
I could only find in systemd.unit(5) the following:
In addition to /etc/systemd/system, the drop-in ".d/" directories
for system services can be placed in /usr/lib/systemd/system or
/run/systemd/system directories. Drop-in files in /etc/ take
precedence over those in /run/ which in turn take precedence over
those in /usr/lib/. Drop-in files under any of these directories
take precedence over unit files wherever located. Multiple
drop-in files with different names are applied in lexicographic
order, regardless of which of the directories they reside in.
To me it makes more sense to place it on the same level as the unit file itself and not spread the config files for the same unit across multiple hierarchy levels.
The /usr/lib/systemd/system is where packages place their default config.
The /etc/systemd/system is where admins are expected to place site-specific customizations.
If you put your config into /etc/systemd/system, then everything that you have done is in one place.
Also, editing/adding stuff under /usr/lib/systemd/system risks being overwritten when packages are upgraded. As @jlehtone and @jbkt23 said the correct place for your own customisations are under /etc/systemd/system be it for existing system ones, or when creating your own.
It’s generally not recommended to do it under /usr/lib/systemd.