On 05/27/2015 02:37 PM, Pavel Machek wrote: > On Wed 2015-05-27 11:09:25, Daniel Phillips wrote: >> On Wednesday, May 27, 2015 12:41:37 AM PDT, Pavel Machek wrote: >>> On Fri 2015-05-15 02:38:33, Daniel Phillips wrote: >>>> On 05/14/2015 08:06 PM, Rik van Riel wrote: ... >>> >>> Umm. Why do you think it is only issue for executable files? >> >> I meant: files with code in them, that will be executed. Please excuse >> me for colliding with the chmod sense. I will say "code files" to avoid >> ambiguity. >> >>> I'm free to mmap() any file, and then execute from it. >>> >>> /lib/ld-linux.so /path/to/binary >>> >>> is known way to exec programs that do not have x bit set. >> >> So... why would I write to a code file at the same time as stepping >> through it with ptrace? Should I expect ptrace to work perfectly if >> I do that? What would "work perfectly" mean, if the code is changing >> at the same time as being traced? > > Do you have any imagination at all? [Non-collegial rhetoric alert, it would be helpful to avoid that.] > Reasons I should expect ptrace to work perfectly if I'm writing to > file: > > 1) it used to work before > > 2) it used to work before > > 3) it used to work before and regressions are not allowed Are you sure that ptrace will work perfectly on a file that you are writing to at the same time as tracing? If so, it has magic that I do not understand. Could you please explain. > 4) some kind of just in time compiler A JIT that can tolerate being written to by a task it knows nothing about, at the same time as it is generating code in the file? I do not know of any such JIT. > 5) some kind of malware, playing tricks so that you have trouble > analyzing it By writing to a code file? Then it already has write access to the code file, so it has already gotten inside your security perimeter without needing help from page fork. That said, we should be alert for any new holes that page fork might open. But if there are any, they should be actual holes, not theoretical ones. > and of course, > > 6) it used to work before. I look forward to your explanation of how. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
