Introduced an API to collect the core from an unrelated process#11
Introduced an API to collect the core from an unrelated process#11ramkums wants to merge 1 commit intoPercona-Lab:masterfrom
Conversation
| /* If pid belong to the one called the library no need to proceed */ | ||
| if (expid == 0 && pid == clone_pid) continue; | ||
|
|
||
| strcat(strcpy(fname, "/proc/"), entry->d_name); |
jlevon
left a comment
jlevon
left a comment
There was a problem hiding this comment.
thanks, I think this looks good to me now
The API WriteCoreDumpOfPID() will take argument pid, and try to collect the core from the process with pid, this uses the existing logic to identify the threads under the given process and to identify the maps and the properties of each memory maps. Then read the memory content from /proc/[pid]/mem, we assume that the caller has the permission to trace and read the mem from process [pid]. A tool also introduced, which will use the API WriteCoreDumpOfPID and provide a convenient CLI for the user, which will help in creating core dump of any process that the user has permission to trace. Following is the help from the tool: Usage: ./coredumper_tool <-c corefile> <-p pid> [-s core_size] [-z] <-h> Show this message and exit <-c core_file> Collect the core dump into a file core_file <-p pid> Collect the core dump of process with pid <-s core_size> Limit the size of core_file to core_size <-z> Compress the core_file on the fly with gzip
ramkums
force-pushed
the
coredumper_tool
branch
from
7cc27b0 to
dd17672
Compare
|
Hello! Thanks for the pull request. @ramkums can you explain the reasoning behind this functionality, what's your usecase? This seems to be already doable with |
Yes, gcore can do it. But it requires the gdb package which is a heavy hammer. And we consider having gdb on a production setup is risky. Moreover we wanted to collect the coredump on specific conditions without user intervention. |
|
You could also make the same point about self-coredump, right? You can also use gcore for that... |
|
Thanks for the quick replies @jlevon, @ramkums!
Security/risk is my main concern too, and that's why I'm asking if there are no workarounds without this feature. On the positive side, I can see how this could make implementing some things in a multi process environment easier, even for us. But the point there is easier, and not possible. I couldn't come up with a single situation, where we can modify the sources of the programs we are using, to actually need this feature. And that's not just with Unless you want to implement a lightweight gcore, or a helper process for pods, without modifying the main app running on the pod itself, which of course can be a use case. On the other hand, this ability can be a potential security risk, a vulnerability in a program using this library could provide an easy way to get a coredump of something else running on the same system, as long as the permissions allow it. |
|
@dutow can you expand on your security concerns a little more, as I'm not quite getting it. You said:
But that would only be a problem if it were possible to elevate privileges as part of this (for example, making that program setuid or it being a privileged daemon). I don't see how that's any different to any other facility: both suid and privileged processes must be written in a secure manner regardless. In particular, a program such as "coredumper" that uses this facility but is not otherwise given additional privileges would not have any security impact, since everything the program can do with this code, the invoking user could do anyway. |
3 participants
The API WritePidCoreDumpWith() will take argument pid, and try to collect the core from the process with pid, this uses the existing logic to identify the threads under the given process and to identify the maps and the properties of each memory maps. Then read the memory content from /proc/[pid]/mem, we assume that the caller has the permission to trace and read the mem from process [pid].
A tool also introduced, which will use the API WritePidCoreDumpWith and provide a convenient CLI for the user, which will help in creating core dump of any process that the user has permission to trace.