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.outas 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
ulimit -cdoesn't report0)? - Some programmer dude