Messages in this thread | | | Date | Fri, 9 Sep 2011 14:44:57 +0200 | Subject | Re: [PATCH 1/2] ptrace: don't modify flags on PTRACE_SETOPTIONS failure | From | "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
| |