Description of problem:
type=AVC msg=audit(1429126124.404:28485): avc:  denied  { read write } for  pid=34885 comm="mail" path="/dev/megaraid_sas_ioctl_node" dev="devtmpfs" ino=26517 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:fixed_disk_device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1429126124.404:28485): arch=c000003e syscall=59 success=yes exit=0 a0=1ad2940 a1=1ad0580 a2=1ad1510 a3=7fff3db58490 items=0 ppid=34884 pid=34885 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="mail" exe="/usr/bin/mailx" subj=system_u:system_r:system_mail_t:s0 key=(null)

Above AVC denied happens if you have a Dell PERC controller (e.g. Dell PERC
H710 in a Dell PowerEdge R720). /etc/smartmontools/smartd.conf needs to be
configured accordingly. If you have SAS drives, use this:

  /dev/sda -d megaraid,0 -a -m root -W 5,5,5

Be sure that you replace the above "0" with the SAS ID your controller uses.
If you have SATA drives, use this:

  /dev/sdb -d sat+megaraid,2 -a -m root -W 5,5,5

Be sure that you replace the above "2" with the SATA ID your controller uses.

Run "systemctl restart smartd.service" - and the AVC denied above will show
up in the logs - the e-mail is however sent even this is denied (enforcing).
Note: I am aware, that "-W 5,5,5" is stupid nonsense, but it triggers really
an event ;-)

Version-Release number of selected component (if applicable):
smartmontools-6.2-4.el7.x86_64
selinux-policy-targeted-3.13.1-23.el7.noarch

How reproducible:
Everytime, see above.

Actual results:
smartd file descriptor leak when calling mailx binary (catched by SELinux)

Expected results:
No smartd file descriptor leak when calling mailx binary.

Additional info:
I guess this is a file descriptor leak, but I might be wrong. However this
is IMHO a bug in the smartd binary and not in the SELinux policy. If there
is need to workaround this in SELinux this should be dontaudit'ed.