Seems something changes recently in the selinux policy on my machine. A simple probe like: stap -e 'probe process("/lib/libc.so.6").function("malloc") {if($bytes > 64 * 1024) log(execname() . " malloc hog!")}' results in several selinux warnings about the ssol area for each program hit Summary: SELinux is preventing sendmail "read execute" access to /uprobes/ssol (deleted). Detailed Description: SELinux denied access requested by sendmail. /uprobes/ssol (deleted) may be a mislabeled. /uprobes/ssol (deleted) default SELinux type is default_t, but its current type is tmpfs_t. Changing this file back to the default type, may fix your problem. File contexts can be assigned to a file in the following ways. * Files created in a directory receive the file context of the parent directory by default. * The SELinux policy might override the default label inherited from the parent directory by specifying a process running in context A which creates a file in a directory labeled B will instead create the file with label C. An example of this would be the dhcp client running with the dhclient_t type and creating a file in the directory /etc. This file would normally receive the etc_t type due to parental inheritance but instead the file is labeled with the net_conf_t type because the SELinux policy specifies this. * Users can change the file context on a file using tools such as chcon, or restorecon. This file could have been mislabeled either by user error, or if an normally confined application was run under the wrong domain. However, this might also indicate a bug in SELinux because the file should not have been labeled with this type. If you believe this is a bug, please file a bug report against this package. Allowing Access: You can restore the default system context to this file by executing the restorecon command. restorecon '/uprobes/ssol (deleted)', if this file is a directory, you can recursively restore using restorecon -R '/uprobes/ssol (deleted)'. Fix Command: /sbin/restorecon '/uprobes/ssol (deleted)' Additional Information: Source Context system_u:system_r:sendmail_t:s0 Target Context system_u:object_r:tmpfs_t:s0 Target Objects /uprobes/ssol (deleted) [ file ] Source sendmail Source Path sendmail Port <Unknown> Host hermans.wildebeest.org Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.6.32-106.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name restorecon Host Name hermans.wildebeest.org Platform Linux hermans.wildebeest.org 2.6.32.10-90.fc12.i686 #1 SMP Tue Mar 23 10:21:29 UTC 2010 i686 i686 Alert Count 4 First Seen Sat 03 Apr 2010 03:08:35 PM CEST Last Seen Sat 03 Apr 2010 03:10:50 PM CEST Local ID be312ed3-2f7a-4326-a424-a27c0ec66d93 Line Numbers Raw Audit Messages node=hermans.wildebeest.org type=AVC msg=audit(1270300250.353:253): avc: denied { read execute } for pid=7984 comm="sendmail" path=2F7570726F6265732F73736F6C202864656C6574656429 dev=tmpfs ino=1499309 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file
Same issue on a slightly newer x86_64 setup (stap version 1.2/0.145, fedora 12, kernel 2.6.32.11-99.fc12.x86_64, selinux-policy-3.6.32-108.fc12): $ stap -e 'probe process("/lib64/libc.so.6").function("malloc") {if($bytes > 64 * 1024) log(execname() . " malloc hog!")}' Results in lots of... Summary: SELinux is preventing sendmail "read execute" access to /uprobes/ssol (deleted). Detailed Description: SELinux denied access requested by sendmail. /uprobes/ssol (deleted) may be a mislabeled. /uprobes/ssol (deleted) default SELinux type is default_t, but its current type is tmpfs_t. Changing this file back to the default type, may fix your problem. File contexts can be assigned to a file in the following ways. * Files created in a directory receive the file context of the parent directory by default. * The SELinux policy might override the default label inherited from the parent directory by specifying a process running in context A which creates a file in a directory labeled B will instead create the file with label C. An example of this would be the dhcp client running with the dhclient_t type and creating a file in the directory /etc. This file would normally receive the etc_t type due to parental inheritance but instead the file is labeled with the net_conf_t type because the SELinux policy specifies this. * Users can change the file context on a file using tools such as chcon, or restorecon. This file could have been mislabeled either by user error, or if an normally confined application was run under the wrong domain. However, this might also indicate a bug in SELinux because the file should not have been labeled with this type. If you believe this is a bug, please file a bug report against this package. Allowing Access: You can restore the default system context to this file by executing the restorecon command. restorecon '/uprobes/ssol (deleted)', if this file is a directory, you can recursively restore using restorecon -R '/uprobes/ssol (deleted)'. Fix Command: /sbin/restorecon '/uprobes/ssol (deleted)' Additional Information: Source Context system_u:system_r:sendmail_t:s0 Target Context system_u:object_r:tmpfs_t:s0 Target Objects /uprobes/ssol (deleted) [ file ] Source sendmail Source Path sendmail Port <Unknown> Host springer.wildebeest.org Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.6.32-108.fc12 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Plugin Name restorecon Host Name springer.wildebeest.org Platform Linux springer.wildebeest.org 2.6.32.11-99.fc12.x86_64 #1 SMP Mon Apr 5 19:59:38 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Tue 20 Apr 2010 12:44:24 PM CEST Last Seen Tue 20 Apr 2010 12:44:24 PM CEST Local ID 55395b13-ba64-4083-afb7-aac52c987f02 Line Numbers Raw Audit Messages node=springer.wildebeest.org type=AVC msg=audit(1271760264.599:39): avc: denied { read execute } for pid=2563 comm="sendmail" path=2F7570726F6265732F73736F6C202864656C6574656429 dev=tmpfs ino=27471 scontext=system_u:system_r:sendmail_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=file
This was filed earlier and then fixed through PR10595 *** This bug has been marked as a duplicate of bug 10595 ***