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

[Colin Walters]

On Tue, 2013-04-30 at 22:32 +0300, Oleksii Shevchuk wrote:

> +                                <term><varname>User=</varname></term>
> +                                <term><varname>Group=</varname></term>
> +
> +                                <listitem><para>Enforce UID/GID of
> +                                <literal>systemd-coredump</literal> while loading
> +                                and storing coredump. 

Like having the "adm" group be able to read core files or something?
Would people really want that?  

> If not set, then uid/gid of

"then the"

> +                                crashed process will be used. This can be used
> +                                for allowing user or group of users
> +                                to have access to system core dumps.

"This can be used to allow a user or group of users..."

> +                        <varlistentry>
> +                                <term><varname>FileStorage=</varname></term>
> +
> +                                <listitem><para>One of
> +                                <literal>volatile</literal> and,
> +                                <literal>persistent</literal>
> +                                value.

"One of <literal>volatile</> or <literal>persistent</>".

> If <literal>volatile</literal>, core dump will be
> +                                stored as file to /run/log/coredump/MACHINE-ID/COMM-TMPSUFFIX location;
> +                                if <literal>persistent</literal> -- to
> +                                /var/log/coredump/MACHINE-ID/COMM-TMPSUFFIX location.

I'm uncertain about including COMM (a user-controlled string) in
filenames.  Perhaps sanitized.

> +                                Storage directory will be created if not exists. If
> +                                <literal>none</literal>, then core dump will not be stored
> +                                as file at all.

"not be stored." ?  But here's where ideally we at least ship something
capable of extracting backtraces.

> +                                <literal>User=</literal> and <literal>Group=</literal>
> +                                not setted, then directory will be created with 1777

"not set".  And really world writable?  Why?  Shouldn't systemd-coredump
be the only thing capable of writing to the directory?  Note we could
open() the fd as root, and then drop privileges.

> +                                <filename>/var/log/coredump/MACHINE-ID</filename>. If value equals
> +                                to zero, then backend will be ommited.

"omitted".

> +                if (!config->user) {
> +                        mode |= S_IRGRP | S_IWGRP | S_IXGRP;
> +                        mode |= S_IROTH | S_IWOTH | S_IXOTH;

Ok right, so looking at the actual code, we setresuid early on to the
dumping user, and then rely on world-writability.   It would be a lot
better to do what I suggested above and call open() first and then drop
credentials?

For what it's worth I just looked at:
http://bazaar.launchpad.net/~daisy-pluckers/whoopsie/trunk/view/head:/src/whoopsie.c
They simply rely on a static kernel core pattern and monitor the
directory with inotify, which is interesting.  The downside I guess is
that the kernel will bindly keep filling up the disk, whereas doing the
dumping in userspace we can have more flexible control over placement
and storage usage.

So...what do you think about dropping the User/Group settings,
having /var/log/coredump have the same permissions as the journal?  I.e.
owned by root:root and with an ACL for access by adm or whatever?