Doubt: core not dumped when binary give up root privileges.
Hi,
I wrote a program which runs with uid 0, but later give up root privs by calling setreuid(x, x) where x is an unprivileged user. Before doing that, it chdirs to a directory owned by that unprivileged user, with mode 700.
The program explicitly sets RLIMIT_CORE to RLIM_INFINITY when still running with uid 0.
If instead of calling the program as root, I call it from the non-priv uid in question, if it crashes, it dumps core on the mentioned dir. That's the desired behaviour, since I can then take the core and debug. But if I run it as root (in fact, I would have to), and it crashes (or is forced to ,by means of kill -SEGV), after it gives up root credentials, it won't leave a core dump file, which in turn means I cannot debug it later.
Any ideas?
Please CC-me since I'm not subscribed.
Thanks,
Alexandre
Ok, now I took the time to read the kernel sources and found why it works like that, and also the "prctl" ioctl.
I guess this should do the trick.
Thanks for the people who gave me some suggestions,
Alexandre
Quoted 2 lines · Alexandre Pereira Nunes
The program explicitly sets
RLIMIT_COREtoRLIM_INFINITYwhen still running with uid 0.
The kernel assumes a core image from something that was priviledged may be unsafe.
Quoted 9 lines
If instead of calling the program as root, I call it from the non-priv uid in question, if it crashes, it dumps core on the mentioned dir. That's the desired behaviour, since I can then take the core and debug. But if I run it as root (in fact, I would have to), and it crashes (or is forced to ,by means of kill -SEGV), after it gives up root credentials, it won't leave a core dump file, which in turn means I cannot debug it later.
Any ideas?
2.4-ac has support for enabling setuid core dumps and setting the dump path, so you can write such dumps to /root/dumps and the kernel will make them root accessible only.
The 2.6 test tree and Marcelo 2.4 don't currently support this
Quoted 11 lines · Alan Cox
Quoted 3 lines · Alexandre Pereira Nunes
The program explicitly sets
RLIMIT_COREtoRLIM_INFINITYwhen still running with uid 0.The kernel assumes a core image from something that was priviledged may be unsafe.
That makes sense... By that time, I took a look at the sources and found the prctl syscall, and with a little tweaking it was possible to do what I wish (keep reading)...
Quoted 8 lines
Quoted 7 lines
If instead of calling the program as root, I call it from the non-priv uid in question, if it crashes, it dumps core on the mentioned dir. That's the desired behaviour, since I can then take the core and debug. But if I run it as root (in fact, I would have to), and it crashes (or is forced to ,by means of kill -SEGV), after it gives up root credentials, it won't leave a core dump file, which in turn means I cannot debug it later.
Any ideas?
Quoted 8 lines
2.4-ac has support for enabling setuid core dumps and setting the dump path, so you can write such dumps to
/root/dumpsand the kernel will make them root accessible only.The 2.6 test tree and Marcelo 2.4 don't currently support this
That's an interesting feature and is almost exactly what I needed: I wrote a daemon, which is started by root at boot time. In some point at startup, it chroot to an application-specific directory and gives up privileges. If it would dump core, it had to be on that directory, which has somewhat restrict permissions, so that I (and only I) can get it later for further analysis. By means of chroot + prctl it was possible to achieve this, but it would be simpler with this approach of yours, which could also help in debugging in case something else crashes. I'm inclined to adopting it, even though the daemon will ship to run on third-parties machines, and I'll have no much control of what kernel is running there (probably distribution default ones). I'll see what is possible here... Thank you!
Alexandre