Re: [PATCH 1/2] ptrace: don't modify flags on PTRACE_SETOPTIONSfailure

[Indan Zupancic]

Hello,

On Fri, September 9, 2011 08:24, Denys Vlasenko wrote:
> It's very unlikely that there is userspace code in the wild which
> will be affected by this change: it should have the form
>
>     ptrace(PTRACE_SETOPTIONS, pid, 0, PTRACE_O_BOGUSOPT)
>
> where PTRACE_O_BOGUSOPT is a constant unknown to the kernel.
> But kernel headers, naturally, don't contain any
> PTRACE_O_BOGUSOPTs, thus the only way userspace can use one
> if it defines one itself. I can't see why anyone would do such
> a thing deliberately.

The only realistic case is when a program compiled on a newer
kernel is run on an older kernel, when it does things like

#ifndef PTRACE_O_TRACEFORK
	opts |= PTRACE_O_TRACEFORK;
#endif

and happened to work on older kernels because it didn't check
the return value.

With the current options the program has to change its behaviour
depending whether the options are available or not, so no problems
should happen in practice, because if a program counts on any
options that didn't exist before, it won't work anyway.

Code that cares about backward compatibility will check at runtime
if the PTRACE_SETOPTIONS fails, and do a new one without the unknown
options.

So it's best to fix this behaviour before introducing new options
that are harmless if the setting of them fails.

Greetings,

Indan


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/