No core dump after setuid

[Timo J]

Is there any way to produce core dump after setuid? User X is running process Y, which is owned by root:sys with suid-bit on. (Process Y needs access to /dev/dlpi through libpcap).

When killing process Y, no core dump is produced. If it's not possible, what would be the best way to allow user X to access /dev/dlpi? (No, I won't change the ownership of that file ;| )

(Regarding to archives, there's no way to get core on this situation...)

[RAC_1]

Which signal ou used?? did you try kill -6 "process"
Make sure you have enough space in current working dir.

Anil

[Timo J]

I used signal 3 (Terminate with core dump). And yes, there is enough room on working directory. (It dumps core ok if I run it as normal user; it can be run and dump core ok as normal user without libpcap feature )

[A. Clay Stephenson]

This is normal behavior. To quote from the man 4 core manpage "A process with an effective user ID different from its real user ID does not produce a core image." Your setuid is not changing the real user id. Man 2 setuid for details and a possible workaround via 2 setuid() calls.

[Rick Beldin]

The kernel prevents setuid or setgid programs from dumping core. There just isn't a way around it. In older HP-UX releases there was a kernel variable you could poke that would allow it, but I believe that feature was removed.

The typical way of handling the issue you talk about - access to a device - is usually handled by a wrapper program. For example, in HP-UX, /usr/bin/X11/X is a wrapper that will call the 'real' Xserver - Xhp or Xf86. Only /usr/bin/X11/X is setuid and that only in a limited area. This is a common technique also seen in Linux OS as well.

[doug hosking]

Due to major security risks there is not a SUPPORTED way of doing this. However:

# echo "dump_all/W 1" | adb -k -w /stand/vmunix /dev/mem

in some releases of HP-UX will likely do what you want. (This syntax changes the running kernel but the change disappears on the next reboot.) Setting dump_all to 0 instead of 1 restores 'normal' behavior.

Again, this is an UNSUPPORTED variable, subject to removal/change at any time without notice. As with any such patching of kernel memory, use at your own risk!!

I stress that making this change introduces a significant security risk to the system. It may be very helpful as a TEMPORARY change for debugging, but is certainly not a change I would recommend on any system that may be subject to hostile users.