Description of problem: When foreman-maintain is used to restart services, it creates new temporary file structures in /tmp: ~~~ # pwd /tmp # ll bundler total 8 drwxr-xr-x 3 foreman-proxy foreman-proxy 17 Jul 19 11:01 . drwxrwxrwt. 17 root root 4096 Jul 19 13:01 .. drwxrwxrwx 4 foreman-proxy foreman-proxy 40 Jul 19 11:01 home # ll systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.service-h892gC total 8 drwx------ 3 root root 16 Jul 19 11:04 . drwxrwxrwt. 17 root root 4096 Jul 19 13:01 .. drwxrwxrwt 3 root root 41 Jul 19 13:04 tmp <--- # ll systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.service-h892gC/tmp total 4 drwxrwxrwt 3 root root 41 Jul 19 13:04 . drwx------ 3 root root 16 Jul 19 11:04 .. drwxr-xr-x 3 foreman foreman 17 Jul 19 11:04 bundler -rw------- 1 foreman foreman 75 Jul 19 11:04 tmp.03odhkcBcP # ll systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.service-h892gC/tmp/bundler total 0 drwxr-xr-x 3 foreman foreman 17 Jul 19 11:04 . drwxrwxrwt 3 root root 41 Jul 19 13:04 .. drwxrwxrwx 3 foreman foreman 20 Jul 19 11:04 home <--- ~~~ Unfortunately it seems that /tmp/systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.servicexxxxxx directory is created with a different name each time foreman-maintain service is restarted. From test lab environment: ~~~ # rpm -qa | grep maintain satellite-maintain-0.0.1-1.el7sat.noarch rubygem-foreman_maintain-0.3.4-2.el7sat.noarch [root@wallsat65 ~]# cd /tmp [root@wallsat65 tmp]# ll total 16 -rw-r--r--. 1 root root 560 Jul 14 20:40 ak_list.log drwxr-xr-x. 3 foreman foreman 18 Jun 15 14:30 bundler drwxr-x---. 2 puppet puppet 18 Jul 17 13:51 hsperfdata_puppet drwxr-xr-x. 2 root root 6 Jul 14 11:29 hsperfdata_root drwxr-xr-x. 2 tomcat tomcat 18 Jul 17 13:51 hsperfdata_tomcat drwxr-xr-x. 2 root root 21 Jul 16 17:41 suds drwx------. 3 root root 17 Jul 17 11:48 systemd-private-382428ce969c4e6686bc4d795d4d2346-httpd.service-ONkg9b <----- drwx------. 3 root root 17 Jul 17 11:48 systemd-private-382428ce969c4e6686bc4d795d4d2346-rh-mongodb34-mongod.service-lMg1l3 drwx------. 3 root root 17 Jul 17 13:50 systemd-private-8c2440013b214a948a39497d82fecb4e-chronyd.service-D7cyE9 drwx------. 3 root root 17 Jul 17 13:51 systemd-private-8c2440013b214a948a39497d82fecb4e-httpd.service-laRiNv <----- drwx------. 3 root root 17 Jul 17 13:51 systemd-private-8c2440013b214a948a39497d82fecb4e-rh-mongodb34-mongod.service-pCmIqT -rw-r--r--. 1 root root 293 Jul 14 18:28 test.csv -rw-------. 1 foreman foreman 12 Jul 17 12:02 tmp.CeYetzNdPT -rw-------. 1 foreman foreman 12 Jul 17 12:09 tmp.kYVZ9nnXxr drwx------. 2 root root 6 Jul 17 13:50 vmware-root_961-4248090753 ~~~ Version-Release number of selected component (if applicable): satellite-maintain-0.0.1-1.el7sat.noarch rubygem-foreman_maintain-0.3.4-2.el7sat.noarch How reproducible: 100% Steps to Reproduce: 1. Restart any service via foreman-maintain 2. Check directories under /tmp 3. Notice each restart of a service has multiple entries Actual results: Multiple directories for each service restart Expected results: No additional files, as security scans would pick this up, causing necessary documentation. Additional info: The customer would prefer that the restarts not generate any new files, as that would have to be documented.
(In reply to patalber from comment #0) > Description of problem: > When foreman-maintain is used to restart services, it creates new temporary > file structures in /tmp: > > ~~~ > # pwd > /tmp > # ll bundler > total 8 > drwxr-xr-x 3 foreman-proxy foreman-proxy 17 Jul 19 11:01 . > drwxrwxrwt. 17 root root 4096 Jul 19 13:01 .. > drwxrwxrwx 4 foreman-proxy foreman-proxy 40 Jul 19 11:01 home > > # ll systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.service-h892gC > total 8 > drwx------ 3 root root 16 Jul 19 11:04 . > drwxrwxrwt. 17 root root 4096 Jul 19 13:01 .. > drwxrwxrwt 3 root root 41 Jul 19 13:04 tmp <--- > # ll > systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.service-h892gC/tmp > total 4 > drwxrwxrwt 3 root root 41 Jul 19 13:04 . > drwx------ 3 root root 16 Jul 19 11:04 .. > drwxr-xr-x 3 foreman foreman 17 Jul 19 11:04 bundler > -rw------- 1 foreman foreman 75 Jul 19 11:04 tmp.03odhkcBcP > # ll > systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.service-h892gC/tmp/ > bundler > total 0 > drwxr-xr-x 3 foreman foreman 17 Jul 19 11:04 . > drwxrwxrwt 3 root root 41 Jul 19 13:04 .. > drwxrwxrwx 3 foreman foreman 20 Jul 19 11:04 home <--- > ~~~ > > Unfortunately it seems that > /tmp/systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.servicexxxxxx > directory is created with a different name each time foreman-maintain > service is restarted. > > From test lab environment: > ~~~ > # rpm -qa | grep maintain > satellite-maintain-0.0.1-1.el7sat.noarch > rubygem-foreman_maintain-0.3.4-2.el7sat.noarch > [root@wallsat65 ~]# cd /tmp > [root@wallsat65 tmp]# ll > total 16 > -rw-r--r--. 1 root root 560 Jul 14 20:40 ak_list.log > drwxr-xr-x. 3 foreman foreman 18 Jun 15 14:30 bundler > drwxr-x---. 2 puppet puppet 18 Jul 17 13:51 hsperfdata_puppet > drwxr-xr-x. 2 root root 6 Jul 14 11:29 hsperfdata_root > drwxr-xr-x. 2 tomcat tomcat 18 Jul 17 13:51 hsperfdata_tomcat > drwxr-xr-x. 2 root root 21 Jul 16 17:41 suds > drwx------. 3 root root 17 Jul 17 11:48 > systemd-private-382428ce969c4e6686bc4d795d4d2346-httpd.service-ONkg9b > <----- > drwx------. 3 root root 17 Jul 17 11:48 > systemd-private-382428ce969c4e6686bc4d795d4d2346-rh-mongodb34-mongod.service- > lMg1l3 > drwx------. 3 root root 17 Jul 17 13:50 > systemd-private-8c2440013b214a948a39497d82fecb4e-chronyd.service-D7cyE9 > drwx------. 3 root root 17 Jul 17 13:51 > systemd-private-8c2440013b214a948a39497d82fecb4e-httpd.service-laRiNv > <----- > drwx------. 3 root root 17 Jul 17 13:51 > systemd-private-8c2440013b214a948a39497d82fecb4e-rh-mongodb34-mongod.service- > pCmIqT > -rw-r--r--. 1 root root 293 Jul 14 18:28 test.csv > -rw-------. 1 foreman foreman 12 Jul 17 12:02 tmp.CeYetzNdPT > -rw-------. 1 foreman foreman 12 Jul 17 12:09 tmp.kYVZ9nnXxr > drwx------. 2 root root 6 Jul 17 13:50 vmware-root_961-4248090753 > ~~~ > > Version-Release number of selected component (if applicable): > satellite-maintain-0.0.1-1.el7sat.noarch > rubygem-foreman_maintain-0.3.4-2.el7sat.noarch > > How reproducible: > 100% > > Steps to Reproduce: > 1. Restart any service via foreman-maintain > 2. Check directories under /tmp > 3. Notice each restart of a service has multiple entries > > Actual results: > Multiple directories for each service restart > > Expected results: > No additional files, as security scans would pick this up, causing necessary > documentation. > > Additional info: > The customer would prefer that the restarts not generate any new files, as > that would have to be documented. These files which are created are world-writable, which is why the security scans flag them. Making them read-only may be better.
There are two distinct issues reported in this BZ: 1. # ll systemd-private-91dc2d256d974b1d84cca9b2f539ab49-httpd.service-h892gC/tmp/bundler 2. # ll /tmp/bundler ~~~~~~ Issue #1: /tmp/systemd-private-*-httpd.service-*/ This directory will be created every time httpd is started. This behavior is part of how Systemd handles temporary files [1] required by daemons (including httpd). When `PrivateTmp=true` is set for a daemon, it will create this directory. ref: /etc/systemd/system/multi-user.target.wants/httpd.service The directory /tmp/systemd-private-*-httpd.service-*/ is created with 700 and root:root, therefore what's inside it should be inaccessible to unprivileged users and shouldn't raise alarms in security scans. PrivateTmp directories are created with random names after each restart. This is by design from RHEL 7 onwards. Please let me know if this conclusion is incorrect. [1] https://access.redhat.com/blogs/766093/posts/1976243 Issue #2: /tmp/bundler Looking at `/usr/lib/systemd/system/foreman.service` and `/usr/lib/systemd/system/foreman-proxy.service`, these Systemd unit files don't ship with `PrivateTmp=true` because of which they're creating /tmp/bundler directories. I'll go ahead and submit a PR in the upstream to set `PrivateTmp=true` for `foreman` and `foreman-proxy` services, with the intention of initiating a discussion on the merits/demerits of `PrivateTmp` for these services.
VERIFIED. @Satellite 6.10.0 Snap10.0 foreman-service-2.5.2-1.el7sat.noarch foreman-dynflow-sidekiq-2.5.2-1.el7sat.noarch by the following manual steps: # ll -d /tmp/bundler* drwx------. 2 foreman-proxy foreman-proxy 6 Jul 27 11:03 /tmp/bundler20210727-62496-14zfo7o62496 # ll /tmp/bundler* total 0 >>> /tmp/bundler* dir is now empty (no world writable home subdir) # ll /tmp/systemd-private-*/tmp/bundler* /tmp/systemd-private-c1f0dc5c86cd44bc807e2aa724be7658-dynflow-sidekiq/tmp/bundler20210727-61753-scwnpt61753: total 0 /tmp/systemd-private-c1f0dc5c86cd44bc807e2aa724be7658-dynflow-sidekiq/tmp/bundler20210727-62417-1id78p662417: total 0 /tmp/systemd-private-c1f0dc5c86cd44bc807e2aa724be7658-dynflow-sidekiq/tmp/bundler20210727-62416-1qcg2ux62416: total 0 /tmp/systemd-private-c1f0dc5c86cd44bc807e2aa724be7658-foreman.service-I9iCEz/tmp/bundler20210727-61734-1f17vxu61734: total 0 >>> no world writable content under systemd dirs # grep -nr PrivateTmp= /usr/lib/systemd ... /usr/lib/systemd/system/dynflow-sidekiq@.service:10:PrivateTmp=true /usr/lib/systemd/system/foreman.service:11:PrivateTmp=true ... >>> fixes for foreman.service and dynflow-sidekiq@.service are present
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Satellite 6.10 Release), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2021:4702