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 [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
