After upgrading selinux-policy and selinux-policy-targeted to version 38.17-1.fc38, restarting sendmail.service results in the following error: Jun 19 18:58:54 test-impala.nasuni.com systemd[1]: Starting sendmail.service - Sendmail Mail Transport Agent... Jun 19 18:58:54 test-impala.nasuni.com systemd[1]: sendmail.service: Can't open PID file /run/sendmail.pid (yet?) after start: No such file or directory Jun 19 18:58:54 test-impala.nasuni.com sendmail[1439]: starting daemon (8.17.1): SMTP+queueing@01:00:00 Jun 19 18:58:54 test-impala.nasuni.com sendmail[1439]: unable to write pid to /var/run/sendmail.pid: Permission denied Jun 19 18:59:39 test-impala.nasuni.com systemd[1]: sendmail.service: start operation timed out. Terminating. Jun 19 18:59:39 test-impala.nasuni.com systemd[1]: sendmail.service: Failed with result 'timeout'. Jun 19 18:59:39 test-impala.nasuni.com systemd[1]: Failed to start sendmail.service - Sendmail Mail Transport Agent. Reproducible: Always Steps to Reproduce: 1. Update selinux-policy, selinux-policy-targeted to 38.17-1.fc38 2. Restart sendmail.service 3. Observe that the sendmail journal indicates "unable to write pid to /var/run/sendmail.pid: Permission denied" Actual Results: sendmail.service enters a failed state and is not running Expected Results: sendmail.service should run I am able to work around this issue by: - running "setenforce 0" followed by "systemctl restart sendmail.service" - using audit2allow to generate an updated policy that allows sendmail to unlink and create files in tmpfs - downgrading selinux-policy and selinux-policy-targeted to 38.15-1.fc38
You are right, this permission was a subject of an unfortunate optimization, it will be a part of the next build. You can also try the following scratchbuild: https://github.com/fedora-selinux/selinux-policy/pull/1753 Checks -> Artifacts -> rpms.zip
Fantastic - thank you very much! Those RPMs were built for rawhide/fc39, for which I unfortunately do not have an available environment. Is it safe to install them within a Fedora 38 environment? I'd be happy to verify the fix if I am able.
The F38 and F39 selinux-policy content is currently the same and dnf history undo should be able to restore the previous state.
Thank you very much for your fast and patient responses. I installed the packages and verified that sendmail is now able to restart without error: Jun 20 19:00:55 rivendell.local.worldwidesullivan.com systemd[1]: Starting sendmail.service - Sendmail Mail Transport Agent... Jun 20 19:00:55 rivendell.local.worldwidesullivan.com sendmail[703839]: starting daemon (8.17.1): SMTP+queueing@01:00:00 Jun 20 19:00:55 rivendell.local.worldwidesullivan.com systemd[1]: sendmail.service: Can't open PID file /run/sendmail.pid (yet?) after start: No such file or directory Jun 20 19:00:55 rivendell.local.worldwidesullivan.com systemd[1]: Started sendmail.service - Sendmail Mail Transport Agent. selinux-policy-38.17-1.20230620_223038.eb400a5.fc39.noarch selinux-policy-devel-38.17-1.20230620_223038.eb400a5.fc39.noarch selinux-policy-targeted-38.17-1.20230620_223038.eb400a5.fc39.noarch Thanks again!
*** Bug 2216780 has been marked as a duplicate of this bug. ***
Caught in enforcing mode: ---- type=PROCTITLE msg=audit(06/22/2023 11:42:55.137:566) : proctitle=/usr/sbin/sendmail -bd -q1h type=PATH msg=audit(06/22/2023 11:42:55.137:566) : item=0 name=/var/run/ inode=1 dev=00:18 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:var_run_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(06/22/2023 11:42:55.137:566) : cwd=/var/spool/mqueue type=SYSCALL msg=audit(06/22/2023 11:42:55.137:566) : arch=x86_64 syscall=openat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x7ffc448e2690 a2=O_WRONLY|O_CREAT|O_EXCL a3=0x180 items=1 ppid=1 pid=1639 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=smmsp sgid=smmsp fsgid=smmsp tty=(none) ses=unset comm=sendmail exe=/usr/sbin/sendmail.sendmail subj=system_u:system_r:sendmail_t:s0 key=(null) type=AVC msg=audit(06/22/2023 11:42:55.137:566) : avc: denied { create } for pid=1639 comm=sendmail name=sendmail.pid scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=0 ---- Caught in permissive mode: ---- type=PROCTITLE msg=audit(06/22/2023 11:44:29.993:570) : proctitle=/usr/sbin/sendmail -bd -q1h type=PATH msg=audit(06/22/2023 11:44:29.993:570) : item=1 name=/var/run/sendmail.pid inode=1312 dev=00:18 mode=file,600 ouid=root ogid=smmsp rdev=00:00 obj=system_u:object_r:sendmail_var_run_t:s0 nametype=CREATE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(06/22/2023 11:44:29.993:570) : item=0 name=/var/run/ inode=1 dev=00:18 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:var_run_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(06/22/2023 11:44:29.993:570) : cwd=/var/spool/mqueue type=SYSCALL msg=audit(06/22/2023 11:44:29.993:570) : arch=x86_64 syscall=openat success=yes exit=5 a0=AT_FDCWD a1=0x7ffea13facd0 a2=O_WRONLY|O_CREAT|O_EXCL a3=0x180 items=2 ppid=1 pid=1663 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=smmsp sgid=smmsp fsgid=smmsp tty=(none) ses=unset comm=sendmail exe=/usr/sbin/sendmail.sendmail subj=system_u:system_r:sendmail_t:s0 key=(null) type=AVC msg=audit(06/22/2023 11:44:29.993:570) : avc: denied { write open } for pid=1663 comm=sendmail path=/run/sendmail.pid dev="tmpfs" ino=1312 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=1 type=AVC msg=audit(06/22/2023 11:44:29.993:570) : avc: denied { create } for pid=1663 comm=sendmail name=sendmail.pid scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=1 ---- type=PROCTITLE msg=audit(06/22/2023 11:44:29.993:571) : proctitle=/usr/sbin/sendmail -bd -q1h type=PATH msg=audit(06/22/2023 11:44:29.993:571) : item=0 name= inode=1312 dev=00:18 mode=file,600 ouid=root ogid=smmsp rdev=00:00 obj=system_u:object_r:sendmail_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(06/22/2023 11:44:29.993:571) : cwd=/var/spool/mqueue type=SYSCALL msg=audit(06/22/2023 11:44:29.993:571) : arch=x86_64 syscall=newfstatat success=yes exit=0 a0=0x5 a1=0x7f3e17df6b93 a2=0x7ffea13fab90 a3=0x1000 items=1 ppid=1 pid=1663 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=smmsp sgid=smmsp fsgid=smmsp tty=(none) ses=unset comm=sendmail exe=/usr/sbin/sendmail.sendmail subj=system_u:system_r:sendmail_t:s0 key=(null) type=AVC msg=audit(06/22/2023 11:44:29.993:571) : avc: denied { getattr } for pid=1663 comm=sendmail path=/run/sendmail.pid dev="tmpfs" ino=1312 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=1 ---- type=PROCTITLE msg=audit(06/22/2023 11:44:29.994:572) : proctitle=/usr/sbin/sendmail -bd -q1h type=SYSCALL msg=audit(06/22/2023 11:44:29.994:572) : arch=x86_64 syscall=flock success=yes exit=0 a0=0x5 a1=0x6 a2=0x0 a3=0x1000 items=0 ppid=1 pid=1663 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=smmsp sgid=smmsp fsgid=smmsp tty=(none) ses=unset comm=sendmail exe=/usr/sbin/sendmail.sendmail subj=system_u:system_r:sendmail_t:s0 key=(null) type=AVC msg=audit(06/22/2023 11:44:29.994:572) : avc: denied { lock } for pid=1663 comm=sendmail path=/run/sendmail.pid dev="tmpfs" ino=1312 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=1 ---- # rpm -qa sendmail\* | sort sendmail-8.17.1-8.fc38.x86_64 #
The following SELinux denial appears during the restart of the sendmail service: ---- type=PROCTITLE msg=audit(06/22/2023 11:52:46.986:578) : proctitle=/usr/sbin/sendmail -bd -q1h type=PATH msg=audit(06/22/2023 11:52:46.986:578) : item=1 name=/var/run/sendmail.pid inode=1312 dev=00:18 mode=file,600 ouid=root ogid=smmsp rdev=00:00 obj=system_u:object_r:sendmail_var_run_t:s0 nametype=DELETE cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(06/22/2023 11:52:46.986:578) : item=0 name=/var/run/ inode=1 dev=00:18 mode=dir,755 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:var_run_t:s0 nametype=PARENT cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(06/22/2023 11:52:46.986:578) : cwd=/var/spool/mqueue type=SYSCALL msg=audit(06/22/2023 11:52:46.986:578) : arch=x86_64 syscall=unlink success=no exit=EACCES(Permission denied) a0=0x7ffea13facb0 a1=0x7ffea13f9b85 a2=0xfff a3=0x0 items=2 ppid=1 pid=1663 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=smmsp sgid=smmsp fsgid=smmsp tty=(none) ses=unset comm=sendmail exe=/usr/sbin/sendmail.sendmail subj=system_u:system_r:sendmail_t:s0 key=(null) type=AVC msg=audit(06/22/2023 11:52:46.986:578) : avc: denied { unlink } for pid=1663 comm=sendmail name=sendmail.pid dev="tmpfs" ino=1312 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:sendmail_var_run_t:s0 tclass=file permissive=0 ---- # rpm -qa sendmail\* selinux-policy\* | sort selinux-policy-38.17-1.fc38.noarch selinux-policy-targeted-38.17-1.fc38.noarch sendmail-8.17.1-8.fc38.x86_64 #
I downgraded selinux-policy and selinux-policy-targeted to 38.8-2 on my system as a workaround to get sendmail running again. I can confirm that the issue with sendmail was not present in selinux-policy 38.15-1, but that wasn't easily available for downgrade, so I just went back to 38.8-2 because that was easier.
*** Bug 2216876 has been marked as a duplicate of this bug. ***
FEDORA-2023-ba070ee6ba has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba070ee6ba
FEDORA-2023-ba070ee6ba has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ba070ee6ba` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ba070ee6ba See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ba070ee6ba has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.