SELinux is preventing /sbin/killall5 from getattr access on the file /usr/sbin/sendmail.sendmail. ***** Plugin catchall (100. confidence) suggests *************************** If you want to allow killall5 to have getattr access on the sendmail.sendmail file 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 /sbin/killall5 /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:xdm_t:s0-s0:c0.c1023 Target Context system_u:object_r:sendmail_exec_t:s0 Target Objects /usr/sbin/sendmail.sendmail [ file ] Source pidof Source Path /sbin/killall5 Port <Unknown> Host (removed) Source RPM Packages sysvinit-tools-2.88-1.dsf.fc15 Target RPM Packages sendmail-8.14.4-15.fc15 Policy RPM selinux-policy-3.9.7-9.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.35.6-48.fc14.x86_64 #1 SMP Fri Oct 22 15:36:08 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Wed 03 Nov 2010 06:22:05 PM CDT Last Seen Fri 05 Nov 2010 07:04:32 AM CDT Local ID 403e3574-0056-4394-9c80-bdb1d27a3875 Raw Audit Messages type=AVC msg=audit(1288958672.336:84): avc: denied { getattr } for pid=1456 comm="pidof" path="/usr/sbin/sendmail.sendmail" dev=dm-0 ino=33197 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:sendmail_exec_t:s0 tclass=file pidof,xdm_t,sendmail_exec_t,file,getattr type=SYSCALL msg=audit(1288958672.336:84): arch=x86_64 syscall=stat success=no exit=EACCES a0=7fff12eba510 a1=7fff12eb9460 a2=7fff12eb9460 a3=1 items=0 ppid=1453 pid=1456 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=pidof exe=/sbin/killall5 subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null) pidof,xdm_t,sendmail_exec_t,file,getattr #============= xdm_t ============== allow xdm_t sendmail_exec_t:file getattr;
*** Bug 653722 has been marked as a duplicate of this bug. ***
*** Bug 653723 has been marked as a duplicate of this bug. ***
*** Bug 653724 has been marked as a duplicate of this bug. ***
*** Bug 653725 has been marked as a duplicate of this bug. ***
*** Bug 653726 has been marked as a duplicate of this bug. ***
*** Bug 653727 has been marked as a duplicate of this bug. ***
Antonio, what were you doing when this happened? Also do you use KDE?
I updated a fully updated Fedora 14 Beta to rawhide to help in Testing and I was greeted by a bunch of selinux/sealert denials. I could not get X session started to use abrt to update, I applied updates and got to report all of these to bugzilla. Is there anything I should try to do? I will apply updates if I can get the updates to this machine.
I have a feeling you might need a relabel. touch /.autorelabel; reboot It looks like you are logging in as xdm_t?
(In reply to comment #9) > I have a feeling you might need a relabel. > > touch /.autorelabel; reboot > > It looks like you are logging in as xdm_t? I will try to do this, but booting takes a very lo oo oooo ng time :( I try to login to level 3 and I get a dracut error dropping to a shell and stay there with lots of crytpic messages about radeon and drm??? novlimvalid EDID? # Will see how I can do it? Sorry for not reporting back, but this stops me from even trying at times :(
Ran autorelabel, applied updates, and all is well now. Hope this fixes the issues :) Ran [students@localhost ~]$ sealert -b and got nothing back, just a crash with abrt and it already has a bugzilla entry :) Thanks, Antonio