13
votes

I've noticed that some of my users didn't get a coredump at all after crashing, even when everything else in their configuration seemed correct.

After reading the core(5) man page a bunch of times I noticed this particular point:

[A core dump file is not produced if] The process is executing a set-user-ID (set-group-ID) program that is owned by a user (group) other than the real user (group) ID of the process.

My daemon isn't setuid root, but in a lot of configurations it's started as root, and if the .conf file specifies a username, it drops privileges, with the usual combination:

setgid(gid);
setuid(uid);

When it does this, coredumps are not generated anymore. Everything else in the environment seems to be correct, removing those calls (and staying as root) gets me coredumps as usual.

I tried to change the "real" uid/gid as the man page seemed to suggest, by calling the less-portable setresgid/uid which seem to be suggested often to drop privileges permanently:

setresgid(gid, gid, gid);
setresuid(uid, uid, uid);

I expected that to solve the problem but... it didn't improve at all. Still no coredumps.

Sooo... now what?


Test code:

#include <stdlib.h>

int main(int argc, char **argv) {
        if (argc > 1) {
                setgid(atoi(argv[2]));
                setuid(atoi(argv[1]));
        }
        abort();
}

Usage:

  • ./a.out as any user to just abort without setgid/setuid
  • ./a.out 1000 100 (where 1000 is uid and 100 is gid) as root to drop privileges and watch coredumps not happen.
  • Bonus unintentional feature: pass one parameter, not two, to get SIGSEGV instead of SIGABRT.

I've already tested this in arch linux, centos 6.5 and openbsd 5.3

2
And the unprivileged user/group haven't disabled core dumps (ulimit -c doesn't report 0)? - Some programmer dude
Yeah, unlimited on both sides. And running it as either uid (0 and 1000) without the setuid/gid calls results in coredumps. - dequis
You really have to be more specific for this kind of stuff, Linux distributions do different things here. In particular, there are PAM modules out there, remember ubuntu, that interact with producing core dumps. - Jens Gustedt
I've reproduced this behavior in arch linux, centos 6.5 and openbsd (it's what i had in vagrant). Adding my test code to the question - dequis

2 Answers

2
votes

To force a process to always core dump use the prctl system call.

prctl(PR_SET_DUMPABLE, 1, 0, 0, 0);
1
votes

You have to enable core dumps for applications that have their privileges changed:

echo 2 > /proc/sys/fs/suid_dumpable

I advice you to put that in /etc/rc.local.


For example, here's what I have there:

# This is to enable debugging as a normal user, rather than root
sysctl kernel.yama.ptrace_scope=0

# This is a convenient core file pattern 
# '%e' is the name of the process
# '%p' is the pid of process
sysctl kernel.core_pattern="/tmp/core.%e.%p"

# Enable dump for processes with lowered privileges
echo 2 > /proc/sys/fs/suid_dumpable

# Remove limit for the size of core files
ulimit -c unlimited

Edit:

You can take a look at this neat library, that allows you to manually write core dumps to a custom file : https://code.google.com/p/google-coredumper/

I believe it's exactly what you need.