[systemd-devel] [PATCH] [RFCv7] Optionally save core dumps as plain files

[Dave Reisner]

On Fri, Jun 20, 2014 at 08:02:54PM +0200, Lennart Poettering wrote:
> On Tue, 14.05.13 19:09, Oleksii Shevchuk (alxchk at gmail.com) wrote:
> 
> Heya!
> 
> Sorry for resurrecting this thread from last year. I never found the
> time to merge this, but I finally had a closer look and then sat down
> and tried to isolate out of it what I liked and what I didn't. I
> commited different patches for this though. Sorry for the looooong
> delay!
> 
> So here's what is implemented in git now:
> 
> a) There's a configuration file /etc/systemd/coredump.conf with some of
>    the options you proposed.
> 
> b) We will now store coredumps outside of the journal by default, but
>    you can also place them in the journal only, or at both places.
> 
> c) I hooked this thing up with elfutils' libdw, which gives us pretty,
>    native backtraces in the journal now, without involving gdb or
>    anything like that. Only a minimal (optional) dependency on libdw to
>    get them. And the best thing is that elfutils is actually maintained
>    and can read debuginfo files,  unlike some other options for stuff
>    like this (like libunwind).
> 
> d) I hooked this up with ACLs so that a user can read but not change his
>    own coredumps stored in /var.

This all sounds great.

> What I didn't take: 
> 
> 1) the API to specify external programs for compressing or processing
>    the coredumps. I am really not too fond of doing things with invokign
>    external programs. THat's always chickening out in my eyes, avoiding
>    to solve the problems properly. By using elfutils' libdw we get the
>    backtrace feature nicely integrated now without invoking external
>    programs, I guess the need for PreprocessJournal= is hence redundant
>    with that. There's no support for compression though, but I'd be fine
>    with taking a simple patch for that that directly speaks to the xz
>    APIs. After all we link against the xz already. Of course this would
>    need support in both the coredump hook to transparently compress the
>    coredumps and in coredumpctl on the client side so that "coredumpctl
>    gdb" just works without manual decompression.
> 
> 2) I change the paths to store this in. I drop the coredumps in
>    /var/lib/systemd/coredump/ now. While the journal logs appear to be
>    something worth sharing across the network as "logs"; I am not
>    convinced that the coredumps would fit that category. 

The fact that this path is hardcoded is kind of lousy. See below...

> Anyway, I hope this makes sense.
> 
> With these changes coredumpctl actually is now really useful and just
> works. I have thus dropped the "systemd-" prefix. We should probably
> start advertising it more.

Are there plans to limit the size of the directory in any way? As is,
the default setup is prone to a simple DoS attack as a non-root user:

  while true; do bash -c 'kill -SEGV $$'; done

Cheers,
Dave