Description of problem: I believe that the error here happened when something tried to send an email, possibly to root. Happened at the same time that I got desktop (KDE) notifications << WARNING: Your hard drive is failing Device: /dev/sda [SAT], not capable of SMART self-check >> (which is stuff for another bugreport) I have esmtp with procmail for local mail delivery esmtp-1.0-10.fc19.i686 esmtp-local-delivery-1.0-10.fc19.i686 # cat /etc/esmtprc mda "procmail -d %T" SELinux is preventing /usr/bin/mkdir from 'write' accesses on the directory /. ### comment ### I believe that the error here happened when something tried to send an email, possibly to root. Happened at the same time that I got desktop (KDE) notifications << WARNING: Your hard drive is failing Device: /dev/sda [SAT], not capable of SMART self-check >> (which is stuff for another bugreport) I have esmtp with procmail for local mail delivery esmtp-1.0-10.fc19.i686 esmtp-local-delivery-1.0-10.fc19.i686 Did not have problems with local mail for normal users. # cat /etc/esmtprc mda "procmail -d %T" ############ ***** Plugin catchall (100. confidence) suggests *************************** If you believe that mkdir should be allowed write access on the directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep mkdir /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:system_mail_t:s0 Target Context system_u:object_r:root_t:s0 Target Objects / [ dir ] Source mkdir Source Path /usr/bin/mkdir Port <Unknown> Host (removed) Source RPM Packages coreutils-8.21-11.fc19.i686 Target RPM Packages filesystem-3.2-13.fc19.i686 Policy RPM selinux-policy-3.12.1-74.15.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.12.5-200.fc19.i686.PAE #1 SMP Tue Dec 17 22:35:54 UTC 2013 i686 i686 Alert Count 12 First Seen 2013-12-21 13:29:09 CET Last Seen 2013-12-25 12:44:12 CET Local ID 73f320db-d11f-4219-a3b1-f1b116cbabb1 Raw Audit Messages type=AVC msg=audit(1387971852.248:620): avc: denied { write } for pid=24207 comm="mkdir" name="/" dev="dm-5" ino=2 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir type=SYSCALL msg=audit(1387971852.248:620): arch=i386 syscall=mkdir success=no exit=EACCES a0=bf8dbb0a a1=1ed a2=8055000 a3=bf8dbb0a items=0 ppid=24201 pid=24207 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=mkdir exe=/usr/bin/mkdir subj=system_u:system_r:system_mail_t:s0 key=(null) Hash: mkdir,system_mail_t,root_t,dir,write Additional info: reporter: libreport-2.1.10 hashmarkername: setroubleshoot kernel: 3.12.5-200.fc19.i686.PAE type: libreport
Found the related /var/log/messages entries: Dec 25 12:44:02 localhost smartd[887]: Device: /dev/sda [SAT], not capable of SMART self-check Dec 25 12:44:07 localhost smartd[887]: Sending warning via /usr/libexec/smartmontools/smartdnotify to root ... Dec 25 12:44:10 localhost smartd[887]: Warning via /usr/libexec/smartmontools/smartdnotify to root produced unexpected output (200 bytes) to STDOUT/STDERR: Dec 25 12:44:11 localhost smartd[887]: mkdir: cannot create directory ‘/.esmtp_queue’: Permission denied Dec 25 12:44:11 localhost smartd[887]: unable to create queue dir /.esmtp_queue Dec 25 12:44:11 localhost smartd[887]: /usr/sbin/sendmail: line 83: return: can only `return' from a function or sourced script Dec 25 12:44:11 localhost smartd[887]: Warning via /usr/libexec/smartmontools/smartdnotify to root: successful .... .... [rz@localhost ~]$ ll /usr/sbin/sendmail lrwxrwxrwx. 1 root root 21 Dec 19 23:13 /usr/sbin/sendmail -> /etc/alternatives/mta [rz@localhost ~]$ ll /etc/alternatives/mta lrwxrwxrwx. 1 root root 22 Dec 19 23:13 /etc/alternatives/mta -> /usr/bin/esmtp-wrapper [rz@localhost ~]$ rpm -qf /usr/bin/esmtp-wrapper esmtp-1.0-10.fc19.i686 esmtp wrapper has the line qdir="$HOME/.esmtp_queue" on my system # echo ~root/ /root/ Not sure why it attempts to create .esmtp_queue at / instead
Filed https://bugzilla.redhat.com/show_bug.cgi?id=1048320 which was the condition triggering the email. The main problem is (local) mail delivery, in this case esmtp-wrapper but bugzilla shows similar can happen with mailx (https://bugzilla.redhat.com/show_bug.cgi?id=1023213). This would be easy to fix for esmtp-wrapper (want to fix that anyway) for local mail delivery but trickier if mail to should go somewhere else.
Yes this should be going to the $HOME or to some other directory.
* is it safe to assume that such a directory exists (daemons not running as root without a home dir?) * how to find the correct dir if "$HOME/.esmtp_queue" obviously did not do the trick
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
reopening: this is still a problem for Fedora 22. I think it affects all daemons that use mail delivery of status messages. I noticed it on failing cron jobs: Nov 24 22:42:01 new-host-6.home crond[1147]: mkdir: cannot create directory ‘/.esmtp_queue’: Permission denied Nov 24 22:42:01 new-host-6.home crond[1147]: unable to create queue dir /.esmtp_queue Nov 24 22:42:01 new-host-6.home crond[1147]: /usr/sbin/sendmail: line 83: return: can only `return' from a function or sourced script
*** Bug 1295195 has been marked as a duplicate of this bug. ***
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Description of problem: The error is due to mkdir on / dir but there was no explicit command given for the said operation. It happened by itself. Some media files were being copied from a dir to USB drive, thats's all, thanks Version-Release number of selected component: selinux-policy-3.13.1-158.12.fc23.noarch Additional info: reporter: libreport-2.6.4 hashmarkername: setroubleshoot kernel: 4.4.6-301.fc23.x86_64 type: libreport
*** Bug 1334114 has been marked as a duplicate of this bug. ***
*** Bug 1359417 has been marked as a duplicate of this bug. ***
As already noted, the '.esmtp_queue' directory should not be created under '/' but under some home directory. This happens when sendmail doesn't have the $HOME environment variable set, e.g. when running from a cron job. This problem is being resolved in [1]. Marking as duplicate. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1303305 *** This bug has been marked as a duplicate of bug 1303305 ***