I occasionally get:
Summary:
SELinux prevented kde4-config from writing ./.kde.
Detailed Description:
SELinux prevented kde4-config from writing ./.kde. If ./.kde is a core file, you may want to allow this. If ./.kde is not a core file, this could signal a intrusion attempt.
Allowing Access:
Changing the "allow_daemons_dump_core" boolean to true will allow this access: "setsebool -P allow_daemons_dump_core=1."
Fix Command:
setsebool -P allow_daemons_dump_core=1
Additional Information:
Source Context system_u:system_r:xdm_t:SystemLow-SystemHigh Target Context system_u:object_r:root_t Target Objects ./.kde [ dir ] Source kde4-config Source Path /usr/bin/kde4-config Port <Unknown> Host elijah.suretrak21.net Source RPM Packages kdelibs-4.2.1-4.fc10 Target RPM Packages Policy RPM selinux-policy-3.5.13-54.fc10 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Enforcing Plugin Name allow_daemons_dump_core Host Name elijah.suretrak21.net Platform Linux elijah.suretrak21.net 2.6.27.21-170.2.56.fc10.i686 #1 SMP Mon Mar 23 23:37:54 EDT 2009 i686 i686 Alert Count 2 First Seen Wed 15 Apr 2009 11:56:28 AM EDT Last Seen Wed 15 Apr 2009 01:11:24 PM EDT Local ID 1391a7fb-e6fd-4c5f-b5bf-9c9354857f3a Line Numbers
Raw Audit Messages
node=elijah.suretrak21.net type=AVC msg=audit(1239815484.398:11): avc: denied { create } for pid=3132 comm="kde4-config" name=".kde" scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:root_t:s0 tclass=dir
node=elijah.suretrak21.net type=SYSCALL msg=audit(1239815484.398:11): arch=40000003 syscall=39 success=no exit=-13 a0=8464158 a1=1c0 a2=279ce8c a3=1 items=0 ppid=3131 pid=3132 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="kde4-config" exe="/usr/bin/kde4-config" subj=system_u:system_r:xdm_t:s0-s0:c0.c1023 key=(null)
selinux is preventing kde4 from writing to my .kde directory in my home directory. The suggestion to allow core dumps is obviously incorrect in this situation.
I can build a local policy to correct this but would think it effects far more user than I and may indicate a need for a policy fix.
Regards, John
selinux@lists.fedoraproject.org