Description of problem: This spontaneously happens over and over. SELinux is preventing sendmail from 'open' accesses on the file /var/cache/ddclient/.esmtp_queue/Nvu3P32F/cmd. ***** Plugin catchall (100. confidence) suggests ************************** Se ci credi sendmail dovrebbe essere consentito open accesso al cmd file per impostazione predefinita. Then si dovrebbe riportare il problema come bug. E' possibile generare un modulo di politica locale per consentire questo accesso. Do consentire questo accesso per ora eseguendo: # ausearch -c 'sendmail' --raw | audit2allow -M my-$MODULE_NOME # semodule -X 300 -i miei-sendmail.pp Additional Information: Source Context system_u:system_r:system_mail_t:s0 Target Context system_u:object_r:ddclient_var_t:s0 Target Objects /var/cache/ddclient/.esmtp_queue/Nvu3P32F/cmd [ file ] Source sendmail Source Path sendmail Port <Sconosciuto> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-38.29-1.fc39.noarch Local Policy RPM selinux-policy-targeted-38.29-1.fc39.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name (removed) Platform Linux (removed) 6.5.9-300.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Oct 25 21:39:20 UTC 2023 x86_64 Alert Count 1 First Seen 2023-11-04 20:46:24 CET Last Seen 2023-11-04 20:46:24 CET Local ID 7934ed39-95d4-4b67-b835-c543f82d4d95 Raw Audit Messages type=AVC msg=audit(1699127184.244:928): avc: denied { open } for pid=50410 comm="sendmail" path="/var/cache/ddclient/.esmtp_queue/Nvu3P32F/cmd" dev="sde4" ino=18648704 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 Hash: sendmail,system_mail_t,ddclient_var_t,file,open Version-Release number of selected component: selinux-policy-targeted-38.29-1.fc39.noarch Additional info: reporter: libreport-2.17.11 reason: SELinux is preventing sendmail from 'open' accesses on the file /var/cache/ddclient/.esmtp_queue/Nvu3P32F/cmd. package: selinux-policy-targeted-38.29-1.fc39.noarch component: selinux-policy hashmarkername: setroubleshoot type: libreport kernel: 6.5.9-300.fc39.x86_64 comment: This spontaneously happens over and over. component: selinux-policy
Created attachment 1997191 [details] File: description
When trying to run `sudo systemctl enable --now ddclient.service` I get something similar: /bin/touch: cannot touch '/var/cache/ddclient/ddclient.cache': Permission denied Not sure if that warrants a separate bug.
(In reply to Jonathan Watt from comment #2) > When trying to run `sudo systemctl enable --now ddclient.service` I get > something similar: > > /bin/touch: cannot touch '/var/cache/ddclient/ddclient.cache': Permission > denied > > Not sure if that warrants a separate bug. Without AVC denials I cannot really say, but it looks the same, so hold on. Did any of you need to make a change in setup or is it just after packages installation?
*** Bug 2247994 has been marked as a duplicate of this bug. ***
*** Bug 2247993 has been marked as a duplicate of this bug. ***
*** Bug 2247992 has been marked as a duplicate of this bug. ***
*** Bug 2247991 has been marked as a duplicate of this bug. ***
*** Bug 2247989 has been marked as a duplicate of this bug. ***
*** Bug 2247987 has been marked as a duplicate of this bug. ***
*** Bug 2247990 has been marked as a duplicate of this bug. ***
*** Bug 2247984 has been marked as a duplicate of this bug. ***
*** Bug 2247985 has been marked as a duplicate of this bug. ***
*** Bug 2247982 has been marked as a duplicate of this bug. ***
*** Bug 2247981 has been marked as a duplicate of this bug. ***
*** Bug 2247980 has been marked as a duplicate of this bug. ***
Denials from the duplicates: e type=AVC msg=audit(1699174767.661:1405): avc: denied { write } for pid=129977 comm="mktemp" name=".esmtp_queue" dev="sde4" ino=18645804 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1699174767.661:1407): avc: denied { create } for pid=129977 comm="mktemp" name="FIzHzwwp" scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1699174767.661:1406): avc: denied { add_name } for pid=129977 comm="mktemp" name="FIzHzwwp" scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1699174767.668:1411): avc: denied { read } for pid=129972 comm="sendmail" name="FIzHzwwp" dev="sde4" ino=18739730 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1699174767.670:1412): avc: denied { setattr } for pid=129980 comm="chmod" name="cmd" dev="sde4" ino=18739732 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 type=AVC msg=audit(1699174767.672:1414): avc: denied { unlink } for pid=129981 comm="rm" name="lock" dev="sde4" ino=18739731 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 type=AVC msg=audit(1699174772.678:1417): avc: denied { link } for pid=130042 comm="dotlockfile" name=".lk1300424dave" dev="sde4" ino=18739734 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 type=AVC msg=audit(1699174772.678:1416): avc: denied { read } for pid=130042 comm="dotlockfile" name=".lk1300424dave" dev="sde4" ino=18739734 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 type=AVC msg=audit(1699174767.666:1410): avc: denied { getattr } for pid=129972 comm="sendmail" path="/var/cache/ddclient/.esmtp_queue/FIzHzwwp/cmd" dev="sde4" ino=18739732 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 type=AVC msg=audit(1699174767.665:1409): avc: denied { write open } for pid=129978 comm="touch" path="/var/cache/ddclient/.esmtp_queue/FIzHzwwp/lock" dev="sde4" ino=18739731 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 type=AVC msg=audit(1699174767.665:1408): avc: denied { create } for pid=129978 comm="touch" name="lock" scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 type=AVC msg=audit(1699174767.672:1413): avc: denied { remove_name } for pid=129981 comm="rm" name="lock" dev="sde4" ino=18739731 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1699127184.244:928): avc: denied { open } for pid=50410 comm="sendmail" path="/var/cache/ddclient/.esmtp_queue/Nvu3P32F/cmd" dev="sde4" ino=18648704 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:ddclient_var_t:s0 tclass=file permissive=1 allow system_mail_t ddclient_var_t:dir { add_name create read remove_name write }; allow system_mail_t ddclient_var_t:file { create getattr link open read setattr unlink write };
(In reply to Zdenek Pytela from comment #3) > Did any of you need to make a change in setup or is it just after packages > installation? In my case it was on enabling the service using `sudo systemctl enable --now ddclient.service`. I did first make some changes to `/etc/ddclient.conf` to configure one of the providers. But my issue will happen with no changes at all since the `/bin/touch` invocation that is failing is in ddclient.service itself, invoked by a `ExecStartPre` line. So the service is failing before ddclient even runs.
(In reply to Jonathan Watt from comment #17) > (In reply to Zdenek Pytela from comment #3) > > Did any of you need to make a change in setup or is it just after packages > > installation? > > In my case it was on enabling the service using `sudo systemctl enable --now > ddclient.service`. > > I did first make some changes to `/etc/ddclient.conf` to configure one of > the providers. But my issue will happen with no changes at all since the > `/bin/touch` invocation that is failing is in ddclient.service itself, > invoked by a `ExecStartPre` line. So the service is failing before ddclient > even runs. Thank you; I may not quite understand though what you mean. I think it is not any service which is failing, but rather sendmail as LDA trying to deliver a mail to the ddclient user because /var/cache/ddclient is its home.
Apologies. My issues is a different issue. (In case someone else ends up here in future due to searching for the failure message I got, this turns out to have happened because prior to enabling ddclient.service I tested my ddclient.conf changes by running `sudo ddclient -daemon=0 -debug -verbose -noquiet` from a terminal. That created the file `/var/cache/ddclient/ddclient.cache` with the security context `unconfined_u:object_r:ddclient_var_t:s0`. That context is not compatible with the context that is needed when ddclient is run as a systemd service. To resolve, remove the file `/var/cache/ddclient/ddclient.cache`, then when you enable the ddclient.service `/var/cache/ddclient/ddclient.cache` will be recreated with the security context `system_u:object_r:ddclient_var_t:s0` and run correctly.)
*** Bug 2248510 has been marked as a duplicate of this bug. ***
*** Bug 2248511 has been marked as a duplicate of this bug. ***
*** Bug 2248513 has been marked as a duplicate of this bug. ***
*** Bug 2248512 has been marked as a duplicate of this bug. ***
*** Bug 2249097 has been marked as a duplicate of this bug. ***
*** Bug 2251340 has been marked as a duplicate of this bug. ***
*** Bug 2251341 has been marked as a duplicate of this bug. ***
FEDORA-2023-0637faa33b has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-0637faa33b
FEDORA-2023-0637faa33b has been pushed to the Fedora 39 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-0637faa33b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-0637faa33b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-0637faa33b has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.