On 23/02/2010 20:56, Philip Guenther whispered from the shadows...: > On Tue, Feb 23, 2010 at 9:34 AM, Ted Unangst <ted.unan...@gmail.com> wrote: >> On Tue, Feb 23, 2010 at 11:23 AM, Anthony Howe <ach...@snert.com> wrote: >>> Without the call to setuid, then the daemon will create a core file in /tmp. >>> >>> What I would like to know is how to get a core file when the daemon >>> program uses setuid/seteuid family of functions, which appears to make >>> it subject to kern.nosuidcoredump? I've tried all 3 possible values >> >> Not sure. I added the 2 setting just for scenarios like this, but it >> was several years ago. Looks like it doesn't work. Maybe it never >> did. :( > > Look Ted, you perhaps should feel guilty about other things, but not > that: Anthony's test program dumps core in /var/crash/ Just Fine with > kern.nosuidcoredump=2 and -current, and that code hasn't change in > quite a while.
But it doesn't do that on my OpenBSD servers (4.0 and 4.3) regardless of what I set kern.nosuidcoredump. Remember too that my claim is that without the setuid() function call, it works fine; with the setuid() call it does not. Theo posted else where in the thread ... On 23/02/2010 18:28, Theo de Raadt whispered from the shadows...: >> 3. The program does not use file system setuid bits, BUT does use the >> > setuid() et al. system calls to drop privileges from root to some other > In OpenBSD -- if you change uids, you don't get core dumps. Which I find a very strange choice, but is at least clear in that any program calling setuid function family will never drop core regardless of kern.nosuidcoredump setting. -- Anthony C Howe Skype: SirWumpus SnertSoft +33 6 11 89 73 78 Twitter: SirWumpus BarricadeMX & Milters http://snert.com/ http://nanozen.info/ http://snertsoft.com/
