This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[Bug dyninst/15656] New: SELinux blocks Dyninst attach if allow_execmod is off
- From: "jistone at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: systemtap at sourceware dot org
- Date: Thu, 20 Jun 2013 01:10:06 +0000
- Subject: [Bug dyninst/15656] New: SELinux blocks Dyninst attach if allow_execmod is off
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15656
Bug ID: 15656
Summary: SELinux blocks Dyninst attach if allow_execmod is off
Product: systemtap
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: dyninst
Assignee: systemtap at sourceware dot org
Reporter: jistone at redhat dot com
The current default in Fedora is to have allow_execmod=on (now called
selinuxuser_execmod). This works fine:
$ getsebool allow_execmod
selinuxuser_execmod --> on
$ stap -e 'probe begin, end { println(pp()) }' --dyninst -c 'sleep 3'
begin
end
$ sleep 3 & stap -e 'probe begin, end { println(pp()) }' --dyninst -x $!
[1] 29605
begin
end
[1]+ Done sleep 3
However, without execmod:
$ getsebool allow_execmod
selinuxuser_execmod --> off
$ stap -e 'probe begin, end { println(pp()) }' --dyninst -c 'sleep 3'
begin
end
$ sleep 3 & stap -e 'probe begin, end { println(pp()) }' --dyninst -x $!
[1] 29726
(hang...)
The case with a created process is fine, but attaching a process hangs. On
Fedora 19, this hang is seen in gdb as a stall deep in BPatch::processAttach(),
and I got an SELinux denial message. On RHEL5, this problem was seen as the
target process segfaulting, and then processAttach returns NULL.
Enabling execmod is probably a necessary evil for the way Dyninst works, though
we can investigate that. For now, we already do have sanity checks in stap to
warn about allow_execmem off, and we could extend this for allow_execmod (but
perhaps only for -x PID mode).
--
You are receiving this mail because:
You are the assignee for the bug.