On Do, 28.10.21 00:22, Fedora Development ML (devel@lists.fedoraproject.org) wrote:
> And me mentioning "crash handler" and "no core dumps" together is > not a mistake. A well-designed crash handler does NOT operate on > core dumps, but on live processes. This implies that it should be > triggered by a signal handler within the executable, ideally shipped > by the upstream so that it reports the crashes directly > upstream. (This is how KCrash and DrKonqi work. But also, e.g., > Google Breakpad.) I am sorry but this is a rubbish idea. Don't process crashes from inside the crashed process, you are working in a corrupted environment, with memory issues and you might modify the image as you are part of it. You run with full user creds while doing so, and since crash dumping/backtrace generation is ultimately parsing data that#s a bad idea. If you want to analyze crashes safely then do it strictly offline, i.e. on an immutable, frozen dump of the image, from the outside, and do it in a sandboxed environment, so that your analysis can't easily be exploited. It's the only safe and robust thing you can do if you actually want to do this in an automatic way. (hint: this is what systemd-coredump does. For a reason.) Lennart -- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
