On Sat, 2015-01-17 at 17:04 +0300, Dmitry V. Levin wrote: > On Thu, Jan 15, 2015 at 12:06:51PM +0100, Mark Wielaard wrote: > > And for the deleted test we can probably first call > > prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, 0, 0, 0) to allow eu-stack -p > > to get at the memory image of the deleted-lib.so. > > JFYI, we use the same approach in strace to make some of our tests work > properly on such systems: > http://sourceforge.net/p/strace/code/ci/master/tree/tests/set_ptracer_any.c
Thanks. It felt a bit weird/backwards to do it this way. But if others also work around this brokenness this way it hopefully will be supported for some time. > > So we probably need to figure out how to really fix this. How do other > > tools and libraries work? What if a user wants to see why firefox is > > wonky and does a strace -p $(pidof firefox) or gstack $(pidof firefox). > > Are those tools also broken by default on Arch? Or do they use some > > other trick to work properly? > > A consumer OS in default configuration does not allow ptrace'ing of > firefox for security reasons. If a user wants to ptrace processes other > than direct descendants, there is no other way besides lifting the ptrace > restrictions. > > Unfortunately, there is a consumer culture of wrapping in sudo any command > that fails with EPERM, but that's another problem. Yeah. I don't know precisely what a "consumer OS" is. But crippling things so the user cannot even inspect what their own processes do feels broken. Especially if the only way to work around it is to run everything with elevated privileges. It feels like someone decided that having firefox do inter-process communication through ptrace with something like xchat might be a bad idea (and it probably is). But then "fixed" things by disallowing any inter-process communication. Effectively making users just run everything as root. The correct approach would be to either run such processes in different security domains. Or removing the ptrace capability from processes that don't need it, like firefox or xchat, and make sure they or their children cannot regain that capability. But an approach that makes the user/consumer not be able to introspect what their own processes are doing is broken and will result in less security since users will then run everything as root to regain the capability. Thanks, Mark
