This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 0.161 elfutils test are failing on Linux Arch

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
> JFYI, we use the same approach in strace to make some of our tests work
> properly on such systems:

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]