Hide Forgot
Description of problem: At the end of a run, amanda sends mail of the log. SELinux is preventing this. In enforcing mode I see: type=AVC msg=audit(1312901001.834:76457): avc: denied { append } for pid=18183 comm="mail" path="/var/lib/amanda/Data/amdump" dev=dm-4 ino=527273 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:amanda_var_lib_t:s0 tclass=file type=AVC msg=audit(1312901001.834:76457): avc: denied { append } for pid=18183 comm="mail" path="/var/lib/amanda/Data/amdump" dev=dm-4 ino=527273 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:amanda_var_lib_t:s0 tclass=file type=AVC msg=audit(1312901001.834:76457): avc: denied { read } for pid=18183 comm="mail" path="/var/lib/amanda/Data/log" dev=dm-4 ino=527272 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:amanda_var_lib_t:s0 tclass=file type=AVC msg=audit(1312901001.951:76458): avc: denied { write } for pid=18183 comm="mail" name="21680.1.amanda" dev=tmpfs ino=162693 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir The third item is a leaked file descriptor. The mail command is run from perl with: open3($fh, ">&2", ">&2", @cmd); So any output of the mail command is expected to go to the amdump log. It appears that the mail command is not allowed to create it's temp file. Version-Release number of selected component (if applicable): selinux-policy-3.7.19-106.el6.noarch amanda-3.3.0-2.el6.cora.1.x86_64
What AVC are you getting in permissive mode?
Sorry for the delay, here we go: type=AVC msg=audit(1314789994.636:948630): avc: denied { append } for pid=14918 comm="mail" path="/var/lib/amanda/Data/amdump" dev=dm-4 ino=524886 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:amanda_var_lib_t:s0 tclass=file type=AVC msg=audit(1314789994.636:948630): avc: denied { read } for pid=14918 comm="mail" path="/var/lib/amanda/Data/log" dev=dm-4 ino=524796 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:amanda_var_lib_t:s0 tclass=file type=AVC msg=audit(1314789995.443:948631): avc: denied { ioctl } for pid=14918 comm="mail" path="/var/lib/amanda/Data/amdump" dev=dm-4 ino=524886 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:amanda_var_lib_t:s0 tclass=file type=AVC msg=audit(1314789995.443:948632): avc: denied { add_name } for pid=14918 comm="mail" name="Rs7AM1VB" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir type=AVC msg=audit(1314789995.443:948632): avc: denied { create } for pid=14918 comm="mail" name="Rs7AM1VB" scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1314789995.443:948633): avc: denied { setattr } for pid=14918 comm="mail" name="Rs7AM1VB" dev=tmpfs ino=25852496 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1314789995.443:948634): avc: denied { remove_name } for pid=14918 comm="mail" name="Rs7AM1VB" dev=tmpfs ino=25852496 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=dir type=AVC msg=audit(1314789995.443:948634): avc: denied { unlink } for pid=14918 comm="mail" name="Rs7AM1VB" dev=tmpfs ino=25852496 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file type=AVC msg=audit(1314789997.411:948635): avc: denied { getattr } for pid=14921 comm="sendmail" path="/var/lib/amanda/Data/amdump" dev=dm-4 ino=524886 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:amanda_var_lib_t:s0 tclass=file
Any idea who creates name="Rs7AM1VB" file with initrc_tmp_t context? This means the file is created by an init script or a domain running as initrc_t.
This dovetails nicely with our grid work - the backup jobs are being run as grid jobs and the grid daemons (and the backup scripts) are running as initrc_t. I'll installed the grid policy on this machine as well and see what changes.
Ok, this relates with grid jobs.
*** This bug has been marked as a duplicate of bug 718273 ***