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 -F<fd> 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