2 ms·
Some programs, like sshd and chromium, make use of this fact to change the process name as shown in procfs and ps. On Linux, every string that argv[] and envp[]
by chenxiaolong 4y ago
Some programs, like sshd and chromium, make use of this fact to change the process name as shown in procfs and ps. On Linux, every string that argv[] and envp[] point to are stored in one contiguous block of memory. Programs can change the name of the process by writing a new string starting at *argv[0] and overflowing into the *envp[] memory as needed. (Though the program needs to strdup() the environ[] entries beforehand since they initially point to envp[] strings.)
For example, chromium's implementation: https://source.chromium.org/chromium/chromium/src/+/refs/tags/110.0.5481.44:content/common/set_process_title_linux.cc https://source.chromium.org/chromium/chromium/src/+/refs/tag...
- 10000truths 4y agoInteresting that procfs reads directly from userspace memory to answer queries from /proc/{pid}/cmdline. I wonder what happens if someone unmaps the memory containing those argv/envp strings?
- chenxiaolong 4y agoI just gave it a try in gdb on a C program with an empty main(). The argv/envp data was in this range: 7ffffffdd000-7ffffffff000 rw-p 00000000 00:00 0 [stack] Running `call (int) munmap(0x7ffffffdd000, 0x22000)` in gdb did indeed unmap the stack... and the program segfaulted immediately afterwards. But while the process was still in the stopped state and before it finished crashing/exiting, /proc/<pid>/cmdline was a 0-byte file.