Description of problem: When have mail alerts setup with smartd then the systemd log will contain errors, e.g. smartd[2075]: /usr/libexec/smartmontools/smartdnotify: line 13: /dev/pts/0: Permission denied Version-Release number of selected component (if applicable): smartmontools-5.42-3 mailx-12.5-5 How reproducible: Everytime systemd starts smartd.service Steps to Reproduce: 1. Install vanilla fedora 17 2. Update /etc/smartd.conf to contain "-M exec /usr/libexec/smartmontools/smartdnotify", e.g. /dev/sda -m <emaildest> -n standby,10,q -M test -M exec /usr/libexec/smartmontools/smartdnotify 3. Ensure mailx setup correct to forward emails via smtp, add the following lines to /etc/mail.rc set smtp=<yoursmtpserver> set from=youremail 3. systemctl start smartd.service 4. systemctl status smartd.service Notice the errors in the systemd journal are similar to below: [root@flop ~]# systemctl status smartd.service smartd.service - Self Monitoring and Reporting Technology (SMART) Daemon Loaded: loaded (/usr/lib/systemd/system/smartd.service; enabled) Active: active (running) since Sun, 10 Jun 2012 15:15:10 +0100; 11min ago Main PID: 2075 (smartd) CGroup: name=systemd:/system/smartd.service └ 2075 /usr/sbin/smartd -n -q never Jun 10 15:15:11 flop smartd[2075]: Device: /dev/sdb [SAT], is SMART capable. Adding to "monitor" list. Jun 10 15:15:11 flop smartd[2075]: Monitoring 2 ATA and 0 SCSI devices Jun 10 15:15:11 flop smartd[2075]: Executing test of /usr/libexec/smartmontools/smartdnotify to <emaildest> ... Jun 10 15:15:14 flop smartd[2075]: Test of /usr/libexec/smartmontools/smartdnotify to <emaildest> produced unexpected output (80 bytes) to STDOUT/STDERR: Jun 10 15:15:14 flop smartd[2075]: /usr/libexec/smartmontools/smartdnotify: line 13: /dev/pts/0: Permission denied Jun 10 15:15:14 flop smartd[2075]: Test of /usr/libexec/smartmontools/smartdnotify to <emaildest>: successful Jun 10 15:15:14 flop smartd[2075]: Executing test of /usr/libexec/smartmontools/smartdnotify to <emaildest> ... Jun 10 15:15:17 flop smartd[2075]: Test of /usr/libexec/smartmontools/smartdnotify to filcole produced unexpected output (80 bytes) to STDOUT/STDERR: Jun 10 15:15:17 flop smartd[2075]: /usr/libexec/smartmontools/smartdnotify: line 13: /dev/pts/0: Permission denied Jun 10 15:15:17 flop smartd[2075]: Test of /usr/libexec/smartmontools/smartdnotify to filcole: successful [root@flop ~]# Actual results: Expected results: Additional info:
Phil: did you modify smartdnotify script? that line contains ... 2>/dev/null ||: so it should ignore failures and it should not print any error message Miroslav: AFAIK, there was some smartdnotify selinux bug. smartdnotify is run as: uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:fsdaemon_t:s0 so I guess SELinux blocks access to /dev/pts/0 (root:tty 0620) ?
Michal: only smartd.conf changed - see below: [phil@flop etc]$ rpm --verify smartmontools S.5....T. c /etc/smartd.conf [phil@flop etc]$
Phil, are you getting AVC msgs? # setenforce 0 re-test # ausearch -m avc -ts recent # setenforce 1
Created attachment 598232 [details] smartd SELinux testing Yes I'm getting AVC logs. Full actions attached in smartd-selinux-test.txt, but summary is: [root@flop ~]# ausearch -m avc -ts recent ---- time->Sat Jul 14 09:27:12 2012 type=SYSCALL msg=audit(1342254432.373:364): arch=c000003e syscall=2 success=yes exit=3 a0=1862fe0 a1=241 a2=1b6 a3=0 items=0 ppid=29447 pid=29448 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="smartdnotify" exe="/usr/bin/bash" subj=system_u:system_r:fsdaemon_t:s0 key=(null) type=AVC msg=audit(1342254432.373:364): avc: denied { open } for pid=29448 comm="smartdnotify" name="0" dev="devpts" ino=3 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=unconfined_u:object_r:user_devpts_t:s0 tclass=chr_file [root@flop ~]# setenforce 1
I'm seeing this on a fresh install of Fedora 18, without making any modifications to set up email: Jan 31 15:31:37 diannao smartd[14737]: Device: /dev/sdb [SAT], 1 Currently unreadable (pending) sectors Jan 31 15:31:37 diannao smartd[14737]: Sending warning via /usr/libexec/smartmontools/smartdnotify to root ... Jan 31 15:31:37 diannao smartd[14737]: Warning via /usr/libexec/smartmontools/smartdnotify to root produced unexpected output (160 bytes) to STDOUT/STDERR: Jan 31 15:31:37 diannao smartd[14737]: /usr/libexec/smartmontools/smartdnotify: line 13: /dev/pts/0: Permission denied Jan 31 15:31:37 diannao smartd[14737]: /usr/libexec/smartmontools/smartdnotify: line 13: /dev/pts/1: Permission denied Jan 31 15:31:37 diannao smartd[14737]: Warning via /usr/libexec/smartmontools/smartdnotify to root: successful
I added a fix to F18. selinux-policy-3.11.1-75.fc18
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. 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 prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 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 to Fedora 17's end of life. 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 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 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. Thank you for reporting this bug and we are sorry it could not be fixed.