On: Unfork()

[aloknnikhil]

> Permission to read from or write to another process is governed by a ptrace access mode PTRACE_MODE_ATTACH_REALCREDS check

I presume that is necessary for this in addition to belonging to the same UID?

> As far as I know process_vm_readv isn't even detectable if the agent process is more privileged than the examinee process—so you're free to manipulate your private copy of the application in the comfort of your own address space.

Interesting. This would be really useful in debugging. Many issues don't reproduce except for in specific configurations. Having access to the memory dump of the live process "streamed" to the debugger would be great!

[geofft → aloknnikhil]

"a PTRACE_MODE_ATTACH_REALCREDS check" and "same UID" are roughly synonyms. ("Roughly" because the actual check also permits privileged processes and denies some special cases such as processes that have done a setuid. REALCREDS, if I remember right, is in contrast to the check done on certain files in /proc.)

It's the same check as ptrace itself, so the intuition is "can I strace or gdb this process."

[tempay → geofft]

The big exception to this is inside containers where it is often disabled by default.

[geofft → tempay]

AIUI Docker containers by default deny the ptrace syscall (and presumably process_vm_readv/writev), they don't change the permission check. So /proc/$pid/mem, which uses the same permission check, ought to work.

(This also means that you don't want or need CAP_SYS_PTRACE to get gdb/strace working in Docker, that lets you ptrace anything and also coincidentally turns off the syscall filter. Just turn the filter off, that works without privileging the processes in the container.)

[comex → tempay]

Or if you have an LSM such as Yama or SELinux set to deny ptrace globally.

[justincormack → comex]

Yama lets you ptrace a child process but not others.

[jwilk → justincormack]

By default, yes.

You can also disable ptrace() completely.

(Grep for "ptrace_scope" in the ptrace(2) man page for details.)

[ktpsns → aloknnikhil]

> Having access to the memory dump of the live process "streamed" to the debugger would be great!

This is also possible with standard debuggers, such as GDB: It can attach to a running process and not only examine the memory, but also debug (stop, pause, skip, ...) the stack trace and control flow. Usage is as simple as gdb -p $(pidof my_running_program)

[andrewaylett → ktpsns]

You might also find https://rr-project.org/ interesting -- it lets you step backwards too.

[Enginerrrd → andrewaylett]

Interesting. Without letting storage explode, I can't think of an easy way to do this since computation isn't really reversible.

[saagarjha → Enginerrrd]

You can keep track of the before and after states whenever you do something nonreversible, like a syscall.

[Doxin → saagarjha]

And even then you can probably just store the diff instead of a full image. And even then if you run out of memory you can just start evicting the oldest snapshots.

[Enginerrrd → saagarjha]

There's a lot of nonreversability in the way a processor interacts with memory though.

[fooker → andrewaylett]

gdb supports reverse debugging too

[aloknnikhil → ktpsns]

Right. But the difference is modifying any memory under GDB will be seen by the process. It's not copy-on-write

[coldtea → aloknnikhil]

Isn't that a feature for debugging tho?

[aloknnikhil → coldtea]

Absolutely. I was arguing for "unforking" to say a patched version of the process and verifying a fix without actually modifying the live process.