Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.
Hi,
Josh Stone jist...@redhat.com writes:
Note, there are actually a few commits associated with PR 14245:
thanks for letting me know.
17986f2 PR14245 stapio should not pass inherited relay_basedir_fd
Right, I can see an extra file descriptor being open:
$ stap -e 'probe begin {}' -c ls -l /proc/self/fd
WARNING: side-effect-free probe 'probe_1987': keyword at input:1:1
source: probe begin {}
^
total 0
lrwx-- 1 lindi kurp 64 May 23 09:06 0 - /dev/pts/1
lrwx-- 1 lindi kurp 64 May 23 09:06 1 - /dev/pts/1
lrwx-- 1 lindi kurp 64 May 23 09:06 2 - /dev/pts/1
lr-x-- 1 lindi kurp 64 May 23 09:06 3 -
/sys/kernel/debug/systemtap/stap_eeae76802d0a6271e55c3f687cef638_4280
lr-x-- 1 lindi kurp 64 May 23 09:06 4 - /proc/4281/fd
Could this be a security issue? Could it cause otherwise buggy behavior?
d7f9b5d PR14245 clean up error messages for staprun -d SOMETHING_AWFUL
Is this only a cosmetic issue of printing the wrong error message?
00d577a PR14245: fix staprun-stapio -Ffd passing for -A (attach) mode
This seems to fortunately still work as root so no regression was
introduced in the backport:
$ stap -v -p4 -e 'probe timer.ms(1000) { printf(hello\n); }'
Pass 1: parsed user script and 81 library script(s) using
79728virt/22236res/2424shr kb, in 90usr/20sys/111real ms.
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s)
using 80260virt/23028res/2560shr kb, in 0usr/0sys/4real ms.
/home/lindi/.systemtap/cache/69/stap_6940b8229bf7950f1e2d880991495fa9_593.ko
Pass 3: using cached
/home/lindi/.systemtap/cache/69/stap_6940b8229bf7950f1e2d880991495fa9_593.c
Pass 4: using cached
/home/lindi/.systemtap/cache/69/stap_6940b8229bf7950f1e2d880991495fa9_593.ko
lindi2:~$ staprun -L
/home/lindi/.systemtap/cache/69/stap_6940b8229bf7950f1e2d880991495fa9_593.ko
Disconnecting from systemtap module.
To reconnect, type staprun -A stap_6940b8229bf7950f1e2d880991495fa9_593
lindi2:~$ staprun -A stap_6940b8229bf7950f1e2d880991495fa9_593
ERROR: no access to debugfs; try chmod 0755 /sys/kernel/debug as root
Failed to initialize control channel.
lindi2:~$ sudo staprun -A stap_6940b8229bf7950f1e2d880991495fa9_593
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
hello
56629dd PR14245: have configury look for openat(2) syscall
This should not be needed since the backported patch does not use
#ifdef HAVE_OPENAT.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.
On 05/22/2013 11:25 PM, Timo Juhani Lindfors wrote:
17986f2 PR14245 stapio should not pass inherited relay_basedir_fd
Right, I can see an extra file descriptor being open:
[...]
Could this be a security issue? Could it cause otherwise buggy behavior?
It's a read-only directory handle, so I don't think there's anything
that could be done directly, security or bug-wise.
Indirectly, I was worried that it might expose debugfs files through the
use of syscalls like openat(dirfd, ../path) - but this looks ok. With
a script running, try cd -P /proc/$(pgrep -xn stapio)/fd/3/. That
will give you a working directory within the otherwise-restricted
debugfs, but you can't get out of /sys/kernel/debug/systemtap/.
d7f9b5d PR14245 clean up error messages for staprun -d SOMETHING_AWFUL
Is this only a cosmetic issue of printing the wrong error message?
I think that's it, yes.
00d577a PR14245: fix staprun-stapio -Ffd passing for -A (attach) mode
This seems to fortunately still work as root so no regression was
introduced in the backport:
It's not a regression introduced by your backport, but it's a related
regression of 0700 debugfs. It should also work as non-root:
$ stap -p4 -e 'probe timer.ms(1000) { printf(hello\n); }' -mjosh
josh.ko
$ staprun -L josh.ko
Disconnecting from systemtap module.
To reconnect, type staprun -A josh
$ staprun -A josh
hello
hello
hello
hello
56629dd PR14245: have configury look for openat(2) syscall
This should not be needed since the backported patch does not use
#ifdef HAVE_OPENAT.
Ok.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.
Note, there are actually a few commits associated with PR 14245: $ git log --oneline | grep PR14245 17986f2 PR14245 stapio should not pass inherited relay_basedir_fd d7f9b5d PR14245 clean up error messages for staprun -d SOMETHING_AWFUL 00d577a PR14245: fix staprun-stapio -Ffd passing for -A (attach) mode c5f7c84 PR14245: support /sys/kernel/debug mounted 0700 56629dd PR14245: have configury look for openat(2) syscall It seems you only grabbed c5f7c84, the primary fix, but you may want those followup tweaks too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.
Hi, here's a short discussion I had on #debian-kernel IRC channel with Ben Hutchings: lindi- bwh: what about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706817 ? it was technically broken during the freeze and but got unnoticed since I was testing with experimental kernels and didn't realize that wheezy kernel would change during freeze... lindi- bwh: or should I just use backports as new kernel versions are going to break things anyway? bwh But stap works OK as root, right? bwh (Why would anyone expect stap to not require root?) lindi- bwh: yes it works as root bwh Does it install some program setuid-root, or is that just an option? lindi- bwh: http://anonscm.debian.org/gitweb/?p=collab-maint/systemtap.git;a=blob;f=README.security lindi- bwh: staprun is a setuid program. It holds on to the root privileges only for the least amount of time (as required to verify/load compiled kernel module files). It invokes only stapio, and only as the original (unprivileged) user. bwh OK that's not too crazy :-) lindi- bwh: and you need to be in the stapusr group to execute staprun bwh So I think this is worth fixing in stable but you should talk to the stable release team lindi- bwh: sure lindi- they might be bit busy right now though :) lindi- bwh: can I assume I can paste the above to the bug report? bwh lindi-: OK I backported commit c5f7c84bf1dcc515 now to systemtap 1.7. I'd like to propose this for stable proposed updates (http://wiki.debian.org/StableProposedUpdates) after some testing. Could somebody from systemtap upstream take a quick look at the backport just to make sure I didn't do anything silly? (In case you wonder, I remove the #ifdef HAVE_OPENAT lines to improve readability, we are guaranteed to have openat in wheezy.) Backported patch: http://lindi.iki.fi/lindi/systemtap/wheezy/PR14245-support-sys-kernel-debug-mounted-0700.patch Debdiff between old and new package: http://lindi.iki.fi/lindi/systemtap/wheezy/systemtap_1.7-1+deb7u1.debdiff.txt The directory also contains binaries for amd64 if somebody wants to test the packages: http://lindi.iki.fi/lindi/systemtap/wheezy/ -Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.
Hi - On Tue, May 14, 2013 at 10:50:45AM +0300, Timo Juhani Lindfors wrote: [...] Could somebody from systemtap upstream take a quick look at the backport just to make sure I didn't do anything silly? [...] Backported patch: http://lindi.iki.fi/lindi/systemtap/wheezy/PR14245-support-sys-kernel-debug-mounted-0700.patch [...] Thanks, it looks good on paper. - FChE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.
Hi, Mark Wielaard m...@redhat.com writes: Bug 14244 - Mode 0700 debugfs leads staprun to orphan modules thanks! This seems to be easy to backport. Bug 14245 - Support debugfs mounted 0700 Backporting this to systemtap 1.7 might take some time since the code has been moved around a bit since then. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.
Package: systemtap
Version: 1.7-1+b1
Severity: normal
lindi2:~$ stap -e 'probe begin { exit(); }'
Error, 'stap_4bc579ccda620476940acff20dcae31_4547' is not a zombie systemtap
module.
WARNING: /usr/bin/staprun exited with status: 1
Pass 5: run failed. Try again with another '--vp 1' option.
lindi2:~$ stap -e 'probe begin { exit(); }'
Error, 'stap_4bc579ccda620476940acff20dcae31_4619' is not a zombie systemtap
module.
WARNING: /usr/bin/staprun exited with status: 1
Pass 5: run failed. Try again with another '--vp 1' option.
lindi2:~$ stap -e 'probe begin { exit(); }'
Error, 'stap_4bc579ccda620476940acff20dcae31_4625' is not a zombie systemtap
module.
WARNING: /usr/bin/staprun exited with status: 1
Pass 5: run failed. Try again with another '--vp 1' option.
lindi2:~$ lsmod | grep stap
stap_4bc579ccda620476940acff20dcae31_462531046 0
stap_4bc579ccda620476940acff20dcae31_461931046 0
stap_4bc579ccda620476940acff20dcae31_454731046 0
I guess this is caused by
linux (3.2.29-1) unstable; urgency=low
...
* debugfs: Add mode, uid and gid mount options; set default mode to 700
(Closes: #681418)
-- Ben Hutchings b...@decadent.org.uk Sun, 16 Sep 2012 06:16:38 +0100
which seems to have entered wheezy along with
# [2012-11-03] linux 3.2.32-1 MIGRATED to testing (Britney)
The easy workaround is to run stap as root but another alternative is
mount /sys/kernel/debug -o remount,mode=755
-- System Information:
Debian Release: 7.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages systemtap depends on:
ii libavahi-client3 0.6.31-2
ii libavahi-common3 0.6.31-2
ii libc6 2.13-38
ii libdw1 0.152-1+wheezy1
ii libelf10.152-1+wheezy1
ii libgcc11:4.7.2-5
ii libnspr4-0d2:4.9.2-1
ii libnss3-1d 2:3.14.3-1
ii libsqlite3-0 3.7.13-1+deb7u1
ii libstdc++6 4.7.2-5
ii make 3.81-8.2
ii systemtap-common 1.7-1
ii systemtap-runtime 1.7-1+b1
systemtap recommends no packages.
Versions of packages systemtap suggests:
pn linux-debug none
ii linux-headers-3.2.0-4-amd64 [linux-headers] 3.2.41-2
ii linux-headers-amd64 [linux-headers] 3.2+46
ii linux-image-3.2.0-4-amd64 [linux-image] 3.2.41-2
pn systemtap-docnone
pn vim-addon-managernone
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706817: systemtap: Error, 'stap_...' is not a zombie systemtap module.
On Sun, 2013-05-05 at 12:07 +0300, Timo Juhani Lindfors wrote: I guess this is caused by linux (3.2.29-1) unstable; urgency=low ... * debugfs: Add mode, uid and gid mount options; set default mode to 700 (Closes: #681418) -- Ben Hutchings b...@decadent.org.uk Sun, 16 Sep 2012 06:16:38 +0100 See upstream PR14244 and PR14245 which come with patches: Bug 14244 - Mode 0700 debugfs leads staprun to orphan modules http://sourceware.org/bugzilla/show_bug.cgi?id=14244 Bug 14245 - Support debugfs mounted 0700 http://sourceware.org/bugzilla/show_bug.cgi?id=14245 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
