After rpm upgrade cgi script executed from http not able to access file in /var/tmp

Rocky Linux Tech Help
1

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

httpd-filesystem-2.4.57-11.el9_4.1.noarch
rocky-logos-httpd-90.15-2.el9.noarch
httpd-tools-2.4.57-11.el9_4.1.x86_64
httpd-core-2.4.57-11.el9_4.1.x86_64
httpd-2.4.57-11.el9_4.1.x86_64

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

==> modsec_audit.log <==
–9282b073-H–
Apache-Error: [file “mod_cgid.c”] [line 1196] [level 3] [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
Apache-Handler: cgi-script
Stopwatch: 1726889435322904 251162 (- - -)
Stopwatch2: 1726889435322904 251162; combined=27, p1=16, p2=7, p3=1, p4=0, p5=3, sr=0, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.9.3 (http://www.modsecurity.org/).
Server: Apache/2.4.57 (Rocky Linux) OpenSSL/3.0.7
Engine-Mode: “ENABLED”

–9282b073-Z–

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

any solution of point to consider for this ?

2

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

3

yes, the cgi script is trying to read : /var/tmp/systemStartupInJSON.log
and jboss user is able to access the file and create and modify this file.

4

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.

5

I am glad you found the solution.

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:

[Service]
PrivateTmp=false
6

Though functionally correct, it is my understanding that the override should be in /etc thus:

/etc/systemd/system/httpd.service.d/override.conf
2 Likes
7

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.

8

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.

2 Likes
9

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.

1 Like