Hi all, first post!

I cannot seem to force an SUID program to drop a core on segfault (or presumably any other fault) when run by an unprivilged user. I've searched about and set everything I could think to set. The kernel.core_setuid_ok seemed most promising, but that hasn't seemed to work either. I saw reference to a bug in sysctl.c for my kernel version related to that variable, but I don't see evidence that it directly relates to my problem. Anyone have any ideas? The output below is obtained immediately after a full reboot. I'm using RedHat Enterprise 3, linux 2.4.21-40, and unable to upgrade to 2.6 at this time.

[root@---- root]# cat /etc/sysctl.conf
# Kernel sysctl configuration file for Red Hat Linux
#
# For binary values, 0 is disabled, 1 is enabled. See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1
kernel.core_setuid_ok = 1
kernel.core_pattern = core.%e.%p


[root@---- root]# cat /etc/profile
//snipped
# No core files by default
#ulimit -S -c 0 > /dev/null 2>&1 //Commented out
//snipped
[root@---- root]# ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

[user@---- ~]$ ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 4
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 7168
virtual memory (kbytes, -v) unlimited

[user@---- user]$ cat /etc/security/limits.conf
# End of file
[user@---- user]$ cat /proc/sys/kernel/core_setuid_ok
1
[user@---- user]$cat testcase.cpp
[HTML]
<code>
//file testcase.cpp
#include<sys/resource.h>
#include<unistd.h>
int main(int args, char *argv[])
{
seteuid(getuid());
struct rlimit rlp;
struct rlimit newRlp = {RLIM_INFINITY, RLIM_INFINITY};
getrlimit(RLIMIT_CORE, &rlp);
setrlimit(RLIMIT_CORE, &newRlp);

int *badPtr = NULL;
*badPtr = 5; //forces segfault

return 0; //shouldn't happen
}
</code>
[/HTML]
[user@---- user]$ g++ -g -Wall testcase.cpp -o testcase
[user@---- user]$ su
[root@---- user]# chown root testcase
[root@---- user]# chmod u+s testcase
[root@---- user]# ./testcase
Segmentation fault (core dumped)
[root@---- user]# exit
[user@---- user]$ ./testcase
Segmentation fault
[user@---- user]$ echo 'Dangit, why wont you drop core!?!?'

Hello and welcome to LQ. Hope you like it here.

Can't see anything wrong in your specs, and on my RHEL-3 equivalent box it works:
What's the difference in strace as root and strace as unpriv user?

Excluding timestamps and hex values related to old_mmap and base addresses, the only diff of 'strace -v ./testcase' between root and unpriv user is:

So after putting this on hold and moving onto my next task, I happened to stumble accross an article mentioning prctl(8). I inserted the line
into my test code and it properly dumped a core. So now my questions are:

1) Is this a proper thing to do? Assuming the rest of the code is secure, are there any glaring reasons why I shouldn't release such code into the field?

2) Does this new information shed any light onto why kernel.core_setuid_ok didn't work for me?

Any other information related to the design mentality for suid fault proceedure, or an explaination of the process the OS follows, be it a description or a link to good information would be greatly appreciated. I'm quite keen on security, but I've still got a lot to learn.

Oh yeah,
you did great job with prctl.
Quoting 'man 2 prctl' on PR_SET_DUMPABLE:

"Since Linux 2.4) Set the state of the flag determining whether core dumps are
produced for this process upon delivery of a signal whose default behaviour is
to produce a core dump. (Normally this flag is set for a process by default, but it is cleared when a set-user-ID or set-group-ID program is executed and
also by various system calls that manipulate process UIDs and GIDs). ..."

Ivo.Raisr, please don't resurrect dead threads. Check the dates before you post. Closed.